Re: rhythmbox: gstreamer vs xine

[Thomas Vander Stichele <thomas urgent rug ac be>]

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.

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).

> 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.

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

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).

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.

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".

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.

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

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Excuse me I must have mistaken you
for someone who gave a damn
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/