[gstreamer-bugs] [Bug 565105] Gstreamer does not change from READY back to PAUSED in same cases

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=565105

  GStreamer | gstreamer (core) | Ver: 0.10.19




------- Comment #10 from Mark Nauwelaerts  2009-02-18 11:08 UTC -------
Created an attachment (id=128966)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=128966&action=view)
Debug log of hanging pipeline

Backtrace that goes with the attached log:
Thread 2 (Thread 0x425a5950 (LWP 10808)):
#0  0x00007ff996030b99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x00007ff99731a0e2 in gst_task_func (task=0x8030c0, tclass=<value optimized
out>)
    at gsttask.c:180
#2  0x00007ff9962a0bf7 in ?? () from /usr/lib/libglib-2.0.so.0
#3  0x00007ff99629f054 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0x00007ff99602c3f7 in start_thread () from /lib/libpthread.so.0
#5  0x00007ff995d9bb2d in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ff997766780 (LWP 10783)):
#0  0x00007ff996030b99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x00007ff996a54616 in ?? () from /usr/lib/libgthread-2.0.so.0
#2  0x00007ff9972e6453 in gst_element_get_state_func (element=0x7a87a0,
state=0x0,
    pending=0x0, timeout=18446744073709551615) at gstelement.c:1901
#3  0x00000000004014cf in _do_pause (user_data=<value optimized out>) at
gsttest.c:90
#4  0x00007ff99627998b in ?? () from /usr/lib/libglib-2.0.so.0
#5  0x00007ff996279262 in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#6  0x00007ff99627c516 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0x00007ff99627c7d7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#8  0x0000000000400fdf in main (argc=<value optimized out>,
argv=0x7fff9f78cb48)
    at gsttest.c:225

Summary of what is happening:
* state changes down to READY; playbin2 & co tear down the pipeline and remove
elements, though not all, e.g. audiotee in playsink is put to READY state
* state set to PAUSED again (mainloop), which in turns triggers dynamic
pipeline building (by streaming thread)
* streaming thread (and also possibly mainloop) is setting newly added element
to PAUSED
* however, audiotee is "disregarded", i.e. it is left to the mainloop to set it
to PAUSED.  This may only happen *after* streaming thread has finished building
the pipeline (or at least believes this is fully finished and OK), upon which
streaming resumes.
(see also about log line 1790 and following)
* but, with audiotee still in READY state, this leads to a wrong state, pausing
streaming thread (filesrc loop in this case), and the pipeline can no longer
preroll and make it to PAUSED, so app waits indefinitely for it to be reached


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=565105.