Thanks, that’s very helpful. Could you confirm you see this with local files? The occasional buffering that occurs for the radio streams makes things a bit more complicated and I’d like to make sure it isn’t entirely due to that.
These two bug fixes from https://gstreamer.freedesktop.org/releases/gstreamer/1.12.3.html sound suspicious:
- 786034 : plugins: queue elements: Handle STREAM_START in EOS situation
- 786056 : queue/queue2:: Allow re-usability after EOS
I tried with local files. I only get the problem when starting with a stream and then switching to a local file. I provided another debug output.
local -> stream
local -> local
Both work without a problem.
@kingosticks - apologies for that, you’re absolutely correct. I’ve edited the response so it was accurate.
@avanc glad to know that 1.12.2 worked for you as well; hopefully that will help figure out what is causing the glitch in the latest versions since then.
I doubt i’ll be of much help developing a fix but i’ll take a look and see if I can find something that may jump out.
With these radio stations @avanc was using, it goes wrong for me very occasionally. When when it does, I see the
STREAM_START bus message is received before we signal Gstreamer we want to change state change to
GST_STATE_PLAYING. Previously those events wouldn’t have been allowed through the
queue elements when still in
GST_STATE_READY but since that 1.12.13 bugfix they are. So I see that behaviour can now be different but I don’t yet understand why that prevents the skip from occurring. I would have assumed it would just stop all audio.
Every now and then one of the streams sends me malformed data, maybe the unreliable aspect is related to the problem changing state.