<div dir="ltr">I'm trying to recreate what this person does with his concatenation element that will be in 1.6: <a href="https://coaxion.net/blog/2014/08/concatenate-multiple-streams-gaplessly-with-gstreamer/">https://coaxion.net/blog/2014/08/concatenate-multiple-streams-gaplessly-with-gstreamer/</a><br><br>In a pad probe on the EOS event of a sink pad, I block the source pad of the pad before that sink pad and then I block the sink pad. Then, I unlink the same two pads. The element before the sink pad is a bin of many elements. I then remove the bin from the pipeline and put it in a linked list for disposal outside the probe. Then, I insert a bin that is a prerolled bin of elements like the one that was removed from the pipeline. The new bin was created using the same function I used to create the part I removed. The song before it plays successfully. I lastly set the prerolled bin to a playing state from paused. All of seems to work successfully to the point I described. The problem is when I try to link the pads of those two elements, the main thread locks up. I’m not sure why and debug info isn’t giving me and useful information. Here’s a graph of my pipeline directly before trying to link those two pads: <a href="http://i.imgur.com/6PYDlAU.png">http://i.imgur.com/6PYDlAU.png</a><br><br>I also tried doing all of that in a function run using g_idle_add so it is asynchronous, but I get the same deadlock result when linking the two pads. Here is my code: <a href="https://drive.google.com/file/d/0B9XMbfqJukNfUEVSQzBNQzd3N2c/view?usp=sharing">https://drive.google.com/file/d/0B9XMbfqJukNfUEVSQzBNQzd3N2c/view?usp=sharing</a><br><br>The relevant code is at 556 and the deadlocking pad link occurs at 707.<div><br></div><div><br></div><div>-DJ G.</div></div>