[gst-devel] bug?

[Jorn Baayen]

On Fri, 2002-05-10 at 08:57, Arik Devens wrote:
> > If the mixer catches the new eos signal from the main thread it
> > disconnects the stream and the mixer, and a new stream is dragged in
> > and hooked up. So far so good, scheduler dumps, everything looks
> > alright. But when i try to set the state to GST_STATE_PLAYING again (i
> > set it to NULL before fiddling with the stream, i tried everything,
> > PAUSED, STOPPED ..), it just locks up right there in the
> > gst_element_set_state. This all happens from the main thread.
> > 
> > I spent the last three days playing with this, and I really dont see how
> > it could be a bug in monkeymedia itself ... 
> 
> not that it helps at all but afaik this is a _very_ old bug. if you
> are using the spider it's because it doesn't handle new
> streams. basically gstreamer doesn't handle setting the location on
> the pipeline to a new stream and playing again afaik. this is why in
> gst-player we NULL out the entire pipeline and recreate it when we
> switch to a new song. need to be fixed :-)

Nope, this is not the problem. For every different file a new
MonkeyMediaStream (containing the source and spider elements) is
created, and the old one is disposed. The only bit that is persistent is
the MonkeyMediaMixer, but this is just a GstThread with volume and
audiosink elements. (of which the volume element is hooked up to the 
current MonkeyMediaStream).

Cheers
Jorn