[Gstreamer-bugs] [Bug 111025] New - Rhythmbox buffering fails because of broken GstThread

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=111025

Changed by in7y118 at public.uni-hamburg.de.

--- shadow/111025	Thu Apr 17 10:18:01 2003
+++ shadow/111025.tmp.22943	Thu Apr 17 10:18:01 2003
@@ -0,0 +1,44 @@
+Bug#: 111025
+Product: GStreamer
+Version: HEAD CVS
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: major
+Priority: Normal
+Component: gstreamer (core)
+AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
+ReportedBy: in7y118 at public.uni-hamburg.de               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.6.x
+URL: 
+Summary: Rhythmbox buffering fails because of broken GstThread
+
+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.