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.
Currently, I have some additional problems. As I don’t know if they are related to the gstreamer problem, I want to summarize them here. If they are not related, I can created another thread or create tickets.
- For some mp3s I get the warning “Track shorter than 100ms” while scanning the library. However, audacity shows that they are aprox 800ms long (e.g. n-joy.mp3).
- Other short tracks ( larger than the 100ms, which are only TTS of the Radio station) can be played directly. However, the play queue stops if they are reached (e.g. mdr_jump.mp3).
I stored the affected songs here (let me know if another service is preferred next time):
Any hints would help.
We’ve checked in some fixes to address this issue and they will be available in the next release (or from github right now).
Thanks for the support. Which branch shall I test? Master or develop?
Develop or release-2.2