<div dir="ltr"><div>Did any of the developers had a chance to take a look ? I might want to investigate the reasons next weekend, but it might be helpful to have some rough plan of action.</div><div><br><div>This is essentially a regression from 0.10: gapless playing of non-file URIs used to work with the suggested about-to-finish callback, but doesn't with 1.0.</div>
<div>(but in 0.10 it was leaking threads...)</div>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 April 2013 23:13, Henner Zeller <span dir="ltr"><<a href="mailto:h.zeller@acm.org" target="_blank">h.zeller@acm.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>I am maintainer of gmrender-resurrect [1], a UPnP renderer (forked from the dormant 'gmrender' project). It is using gstreamer as backend.</div>
<div><br></div><div>Using the gstreamer "playbin" feature to set the next URI in an "about-to-finish" callback, this UPnP renderer successfully implements gapless playback, alas, not without trouble.</div>

<div><br></div><div>It turns out, that playing gapless with inputs from HTTP-URLs is leaking threads, up to the point that things stop working. This is with gstreamer-0.10. With gstreamer-1.0 setting HTTP URLs in the "about-to-finish" callback does not seem to work at all.</div>

<div><br></div><div>This _does_ work with local file-URIs, so I believe this has to do with different handling of network resources vs. local resources, i.e. buffering, probably a separate thread handling the network input (and it would explain why this hasn't been noticed before, because the usual use-case is to read from files).</div>

<div><br></div><div>To reproduce, I created simplified test-code including Makefile and test-sound in this public git repository that illustrates the behavior:</div><div><br></div><div>  <a href="https://github.com/hzeller/gstreamer-gapless-test" target="_blank">https://github.com/hzeller/gstreamer-gapless-test</a></div>

<div><br></div><div><div>All it does is to re-set the original URI back once the "about-to-finish" callback is called ... and exhibiting the described behavior:</div><div><div>  - gstreamer-0.1: runs out of threads on gapless playing URIs</div>

<div>  - gstreamer-1.0: does not handle well having the URI set in about-to-finish callback.</div></div><div>   - both work with file URIs</div><div><br></div></div><div>Instructions to reproduce are under</div>
<div>  <a href="https://github.com/hzeller/gstreamer-gapless-test/blob/master/README.md" target="_blank">https://github.com/hzeller/gstreamer-gapless-test/blob/master/README.md</a><br></div><div><br></div><div>Maybe, this is a usage error, but I suspect it to be a bug. If you can confirm that this _should_ work, then I am happy to file a bug, and probably dig into the code to help working on a fix.</div>

<div><br></div><div>Thanks,</div><div>  Henner.</div><div><br></div><div>[1] <a href="https://github.com/hzeller/gmrender-resurrect" target="_blank">https://github.com/hzeller/gmrender-resurrect</a></div></div>
</blockquote></div><br></div>