GNOME Bugzilla – Bug 487568
gnonlin: Pipeline freezes when adding/removing GnlCompositions/GnlSources while PLAYING
Last modified: 2014-11-26 15:45:51 UTC
Steps to reproduce: Run the attached Python script bug.py. This repeatedly adds and removes three compositions with a audio gnlsource in each to/from the pipeline while playing. I apologize if the bug is in the script itself, I posted it to the gst mailing list, but received hardly any feedback. Stack trace: Other information: Script seems to freeze exclusively when attempting to "Remove Track". Possible error messages (varies): 1. (bug.py:8849): GStreamer-WARNING **: loop detected in the graph !! 2. sys:1: Warning: g_node_find: assertion `root != NULL' failed 3. (no message, just stalls!)
Created attachment 97373 [details] Test script to reproduce the bug
Hi, the big issue with your script is that you're trying to synchronously block pads. The API documentation regarding gst_pad_set_blocked_async() will tell you why: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPad.html#gst-pad-set-blocked-async What you want to do is give a callback, and in the callback do what you wanted to do once that pad was blocked. You have to adopt the same paradigms as with event-based programming. Please adjust your script accordingly and confirm if that fixed your issue.
Created attachment 97976 [details] Updated test script with async pad blocking OK, here is my script adjusted to use async pad blocking. However, it seems that the freezes occur mostly when attempting to remove a track whose srcpad has not been created yet (lines 64ff), so blocking doesn't seem to play a role here.
Dominique, a lot happened in the past year and a half in gnonlin, do you still see this issue with the current 0.10.10.2 pre-release ?
Sorry, using gnonlin-0.10.10.2 on Ubuntu 8.10 the freezes still occur. (In reply to comment #4) > Dominique, a lot happened in the past year and a half in gnonlin, do you still > see this issue with the current 0.10.10.2 pre-release ? >
grmbl, still happens
Created attachment 247860 [details] Same test ported to Gst 1.0 I have ported this test to Gst 1.0 and runned it on current git master of GNonLin and it does not crash anymore. Though I seems to hang after a while.
Created attachment 247863 [details] Same test ported to Gst 1.0 There was few porting errors. I did a second pass, fixing probe and adding "commit" emission as pad-added will never be called otherwise. So far it crashes in python, there must be something do do in pad-added as it's called from a separate thread. I'll probably just rewrite this in C to at least verify if this bug still exist.
What's up with this? Nicolas, are you going to port your Gst 1.0 test case to C? Is anyone still interested in fixing this or shall we close this seeing that gnonlin is about to be replaced?
Actually this is properly support and tested in NLE so let's just close as "obselete"