Audio dropout before track change #1409
Comments
This is kinda expected, with the gapless changes the audio system does a blocking callback to get the next uri, so if you don't get the next track going before the audio buffers run out... Main thing we can do for this is make the queue sizes bigger to give backend more time to get the next track going. |
What about making the call of |
No, sadly not. It explicitly needs to be blocking as the GStreamer pipeline needs to have the next URI set before the about-to-finish signal callback returns. If it doesn't get set the pipeline will stop. |
Thing we can do for this before 2.0 is basically just add a setting for the buffer time of the queue we have before the tee. I would say to leave it blank by default, so use gst defaults, and then let people running into this increase to buy slow backends enough time to get the next uri. |
It may help to increase this for users that are experiencing buffering before track changes. Workaround for mopidy#1409.
Fixed by PR #1442. |
The fix does not help. I still have the audio dropout before track change. If I increase the audio.buffer_time than the dropout is earlier (buffer_time=10000 -> dropout 10 seconds before end). With a large buffer_time I also get a dropout short after starting a new track from queue. |
With the current
develop
version I have audio dropouts a few seconds before a track change. The dropout occurs exactly when mopidy callsPlaybackProvider.translate_uri
.In my backend
PlaybackProvider.translate_uri
blocks ~ 0.6 second for an internet access.The text was updated successfully, but these errors were encountered: