[gst-devel] resend ...
Thomas Vander Stichele
thomas at urgent.rug.ac.be
Mon Jan 13 01:57:02 CET 2003
This mail got denied because the address was wrong. I used reply to all,
so it's kind of telling that the address was wrong in the first place :)
>>>
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gst-devel at lists.sourceforge.net
unknown local-part "gst-devel" in domain "lists.sourceforge.net"
------ This is a copy of the message, including all the headers. ------
>>>
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/
More information about the gstreamer-devel
mailing list