Re: rhythmbox: gstreamer vs xine

[Jorn Baayen <jorn nl linux org>]

Hi,

On Mon, 2003-01-13 at 10:35, Thomas Vander Stichele wrote:
> Hey Jorn,
> 
> > Hi,
> > 
> > I'm mailing to let you know I have been moving CVS Rhythmbox
> > (monkey-media) to use xine instead of GStreamer.
> 
> Yesterday I finally got round to installing Phoebe on my home machine.  Of 
> course, I was excited to see rpms like gstreamer, nautilus-media and 
> rhythmbox be installed automatically.  It felt like it was more real than 
> it has been in the past.
> 
> I tried both out, and because nautilus-media wouldn't scan properly, I 
> enabled the known workaround for osssink synchronisation in my gconf key.  
> After that, I couldn't start Rhythmbox.  I remember having made a patch 
> for this issue in Rhythmbox for "our" rpm's of it.  Basically, Rhythmbox 
> didn't parse the gconf key using the GStreamer API provided, as I 
> suggested when we discussed the implementation a long time ago, but was 
> just assuming the gconf key to be a fixed element instead of a parsable 
> pipeline.
> 
> I was thinking, "I need to discuss this patch with Jorn so it gets 
> integrated", but now it looks like that isn't really necessary anymore.

Well, I fixed that a few days ago. (I didn't know about the params stuff
until someone told me, maybe you told me earlier, guess I forgot then)

Well, you should just have sent me that patch I guess, if it was in your
rpms anyway.

> 
> I'll be sad to not see Rhythmbox in Red Hat 8.1.  While it was far from 
> finished, I was looking forward to at least being able to recommend it to 
> a whole bunch of people I know, and at the college radio I also work at in 
> my spare time (they moved to RH exclusively last year, finally).

Actually I am pretty relieved rb wont be there - it is far from ready,
it wouldnt work for very well for many people, it'd get a bad
reputation, etc. Plus we'd be flooded with bug reports and many users,
which would be great, if only it were ready.

(I asked jrb to check with me before putting it in rh81, I hope he will
:) )

> 
> > While I prefer the
> > gnomishness of the GStreamer API over xine, GStreamer is still not very
> > stable,
> 
> With the previous account of that gconf problem, I just wanted to touch
> on what I think is a more fundamental problem than what you call 
> "GStreamer not being stable".  It's a typical case of not having enough 
> communication.  AFAIK, you've been in #gstreamer for no more than a day 
> over the past year.  You've filed five bugs against GStreamer, all of 
> which got taken into account, worked on and fixed.  I mostly only found 
> out about issues in rhythmbox by hanging out in #rhythmbox myself.  And 
> when you complained about them, I offered help and suggestions every time.

Sure. I'm not saying you guys have not been helpful or anything, the
contrary. Anyway I thought you guys knew about the issues, I mean every
time you or Uraeus said that 'the sched was broken, indeed' or something
like that. Well, fair enough, I thought, will get fixed sooner or later.
But I've been hacking on rb for a year now, and still it woulnt play
reliably.

> 
> I'm just not sure most of those suggestions ever made their way into the 
> code; see the gconf example.

That gconf thing is indeed a case of miscommunication, but I guess
that's also due to the lack of changelogs in gstreamer. Most CVS modules
keep one, and it allows you to keep track on what is changeing, so you
know what to look for. But if you just have to guess.. or hear it from
others...

> 
> It wasn't very easy for me to always use Rhythmbox either - numerous UI 
> overhauls and various stages of brokenness sometimes got in the way.  But 
> I just kept the last good version around and it served me well.  On my 
> laptop, I've ran rhythmbox for days on end without any problems.  This 
> allowed me to fix stuff in GStreamer, or at least report it, so that 
> Rhythmbox worked better.
> 
> FWIW, basically the only issue you have is quite simply, using i686 glibc 
> on Red Hat with the thread-based schedulers.  This problem :
> a) only happens on i686 glibc redhat (which not only uses different opt 
> flags, but a different code path in the source code)
> b) doesn't happen with i386 glibc (which you can easily install)
> c) doesn't happen with the optimal scheduler wim wrote (which just needs a 
> few more tweaks to get right).

I've been trying with the opt scheduler many times the last week, but it
never did anything better than the standard one..

> 
> If you had wanted to actually develop Rhythmbox, you could've just 
> installed i386 glibc and got on with it, knowing that Wim is working very 
> hard and doing great work on writing a cothreadless scheduler.

Well, ehm, having to install an i386 glibc is not exactly what you want
though.

But, I tried this once, and it didn't help at all. Maybe something else
was broken at the time too, I don't know (2 months ago or so).

> 
> It's a bit disheartening for us if, after working so hard on Gnome 2.2 
> stuff and hammering out the major user-visible bugs, you suddenly, without 
> any notice or any communication with us, decide to switch to something 
> else on the basis that "GStreamer is unstable".

The situation sucks indeed. I know I'm being a bit of an ass here, and I
feel bad about it. But damn, at one point you have had enough and want
to actually start using your own app.

> 
> Frankly, Rhythmbox uses very little in GStreamer that is unstable.  
> Stability of GStreamer in the areas that Rhythmbox uses has been proven by 
> applications that do a lot more complex processing than the rhythmbox 
> decode ! volume ! adder chain.  I wrote the basics of nautilus-media in 
> two days, and apart from some of the logic of autoplugging it works 
> incredibly well.  So I don't really think the unstability of Rhythmbox can 
> be entirely blamed on GStreamer at all.  And I never gave up on Rhythmbox 
> either, even though it never managed to read trees with much more than 1 
> GB of music, or didn't clean up properly on exit, and so on.

Well, with gstreamer it would crash all the time. When I ported it to
xine, which was the *only* code change, it wouldnt crash at all, even
though i stress tested it for hours.

> 
> Of course, I respect your decision.  I just feel that the way it has been 
> taken is untimely and unfair.  So of course I hope you change your mind 
> some time in the future.
> 
> Open source development works or fails mostly on two things :
> actual work and communication.
> Both GStreamer and Rhythmbox had a lot of actual work put to them, but for 
> some reason the communication didn't work well.
> Communication is achieved through mails, bug reports, and irc.
> Basically, we can't fix bugs that we don't know about.
> 
> So I hope that, in the future, if Rhythmbox ever switches again, we on 
> both ends will take care to make sure we communicate effectively.
> 
> Thomas

Well, my apologies for everything .. I hope however you understand my
situation as well.

Cheers