After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 111025 - Rhythmbox buffering fails because of broken GstThread
Rhythmbox buffering fails because of broken GstThread
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal major
: 0.6.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-04-17 14:18 UTC by Benjamin Otte (Company)
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benjamin Otte (Company) 2003-04-17 14:18:00 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.
Comment 1 Benjamin Otte (Company) 2003-04-22 14:48:26 UTC
THix is fixed in HEAD btw, so I'm closing this.