[gst-devel] bug?

[Jorn Baayen]

Heya,

I bumped into something that probably is a gstreamer bug, i cannot see
what might be wrong here:

Basic monkeymedia arch:

[ MonkeyMediaAudioStream              ]=>[ MonkeyMediaMixer      ]
[ GnomeVFSSrc ]=>[ Spider ]=>[ Volume ]=>[ Volume ]=>[ Audiosink ]

If an EOS event is received from the gnomevfssrc, a signal is prepared
and
put in a signal queue which is processed by a timeout function in the
main thread, so that users dont have to worry about threading issues.

(BTW what would be the best place to catch EOS signals from? gnomevfssrc
emits it too early for proper use in monkeymedia, since it's emitted
when the data ends, not when the playback ends. The audiosink is not an
option either since it's not stream-specific in this case.)

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

If someone could look into this it would be greatly appreciated ..

All the code is in gnome cvs, module monkey-sound.

Thanks,
Jorn