GNOME Bugzilla – Bug 111025
Rhythmbox buffering fails because of broken GstThread
Last modified: 2004-12-22 21:47:04 UTC
Rhythmbox tries to buffer internet radio. This is done by constucting this pipeline (simplified): { src ! queue } ! ( decoder ! audiosink ) and setting the thread to PLAYING. It waits until the queue is full and sets the bin in the back to PLAYING. This works perfectly if you have this in a normal pipeline and start iterating then. However: The above pipeline is put into a thread, so it looks like this: { { src ! queue } ! ( decoder ! audiosink ) } After starting the inner thread, the outer thread is set to PLAYING, too (see gstbin.c:gst_bin_child_state_change for why this is done). The outer thread however will do one iteration, gst_bin_iterate will return FALSE because there's nothing to iterate and the outer thread will stop spinning. The following problems make this fail here: 1) A thread can only be made spinning by changing the state from PAUSED to PLAYING. - It would be better if it could be made to start spinning again somehow as long as the state is PLAYING. 2) A thread does not get any information when one of its children changes its state. (It's informed only about his own state changes) - It would be nice if the thread implementation could overwrite gst_bin_child_state_change to restart spinning. This actually causes a deadlock when a thread changes its state because of this, because the thread waits on a condition to be signalled when the state changes. 3) The state of a bin is equal to the highest state of any child. - It could be nice if it were equal to the highest state of any non-self-scheduling child if there were any.
THix is fixed in HEAD btw, so I'm closing this.