[gst-devel] release

[Benjamin Otte]

On Tue, 13 Apr 2004, Thomas Vander Stichele wrote:

> Hi,
>
> > Hi,
> >
> > The latest GStreamer CVS is rocking for me.  Now, I'd like to release
> > Rhythmbox 0.8.0.  However I don't want to do that until a GStreamer with
> > the memleak fixes (in particular) is out.
>
> > This is all sort of urgent because the freeze for FC2t3 is Thursday
> > evening, and I'd like to have this all in before then...
> >
> > So has anyone committed anything that might even be halfway questionable
> > to CVS?  Looking at the changelog it's a little hard to tell.
>
> Well, a bunch of stuff got commited and I must agree it's hard to tell
> whether or not we should consider head "safe" at the moment.  I've ran
> into some things that might be bugs, or regressions, depending on how
> you look at it.
>
All the code I added from 0.8.0 to now are bugfixes or enhancements that
are optional and not used by default (like the entry scheduler).
So from my point of view cvs is more stable and works better than 0.8.0.

I only intend to change stuff that we need to carefully check after the
next release is out to make release-device-on-pause possible.

> There's another bug I ran into today that breaks playback of mp3 files
> with spider (#139926), because spider sometimes plugs a few id3tag
> elements in a row (since id3tag can serve three different caps,
> depending on some heuristic, one of which is the same as the sink
> caps).  This depends on the order in which it traverses element
> factories, at the moment, which is semi-random (ie depends on your local
> layout :))
>
A simple fix should be to reduce the rank of id3tag by 1 to
GST_RANK_PRIMARY - 1. This would ensure that mad is always piecked before
id3tag I think.

The correct fix is to replace id3tag by id3demux/id3mux elements. People
should push me more to get that done. Though it's probably better to do
that post-0.8.1 if the above fix works.

> These are the three bugs I know about that would directly affect
> RhythmBox and may be serious enough to fix first.  Although, the first
> and the third were also in 0.8.0 to the best of my knowledge (I can't
> reproduce the third with 0.8.0 because it happens to check mad before
> id3tag for me).
>
If anyone's keen to test:
This should be possible to check by either modifying the registry and
switching the plugins or by changing the order in which the elements are
registered in mad's plugin_init.

Benjamin