Interrupted playback at the end of tracks #4393
Labels
Comments
|
Hi all. Thanks so much for the report. I think that we should focus on issues seen with Since the issue takes a long time to materialize, any documentation about it would help:
These would be a pretty good starting point. Thanks! |
|
|
Thanks. I'm prioritizing this one in the coming week. |
|
Another question: What time implementation are those using? This like from the config: As usual, please post configurations, this helps a lot. Thanks! |
|
Azuracast uses bookworm deb as always. |
|
Well this might have been quite a stupid bug after all. Are y'all able to test the latest I remember how this felt like a similar bug: #4187 I'm guessing that this is due to some resources accumulating and dragging the runtime after a while. Turns out I might have misused some of the functions for filtering queues. This PR: #4406 fixes that. Would be great if that was the source of the issue! |
|
It would! I'll switch to that and try to spin up Azuracast instance as well. @unudelaradio, can you test your test instance with this version? |
|
I just pushed a rebuild of |
|
So finally after 12 hours I got something. Catch ups have been steadily increasing from 0 to 4 seconds in 12 hours. And now once in a minute or two you can here a tiny gap. I think it will grow. Commit 748cd0c Script - https://paste.rs/nZVa9.txt . Autocue is Moonbase's autocue. But I think it really doesn't matter. Two 15 second mp3 tracks playing. Logs level 4 - nothing interestingCPU spiked up to from 5-7% to 20-40% and memory increased twice (observed just via 'top'). Alpine official docker build. Will try to get more details. |
|
Hello, and many thanks for prioritizing this! I hope this discussion will soon resolve the issue with the gaps
@gAlleb I’d be happy to test and see if any changes help. I assume I need to make some custom modifications to my AzuraCast installation to test this Liquidsoap build. Could you please guide me? |
|
It's quite straight forward: But I think you should wait for another release - cause as we see - current changes haven't solved the problem. |
|
You're right, thank you! I'm also happy that you were able to replicate the problem on your install. |
|
@unudelaradio Hi! Could you try with this build? https://github.com/savonet/liquidsoap/actions/runs/13949419215/artifacts/2781319081 It's a zip file - inside is Don't forget to uncomment or switch back crossfade. |
|
@gAlleb Hello, and thank you! On one of the servers (Cloud Fanatic), the new build is already running. https://cloudfanatic.heavyrotation.ro/listen/brandingradio/live I'm not sure why, but on the other server (Oracle Cloud), I get an error message after executing the install command: Here’s the error message I receive: |
|
Not sure what's up with |
|
Things we've learned while investigating this:
This PR: #4410
Please feel free to test this branch! You'll need the soon to be in opam package for Would love to confirm that this fixes at least some issues and schedule a bugfix release soon. |
|
Thanks, @toots. Let's hope it fixes the issue. |
|
After 12 hours of running latest
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
As per discussion AzuraCast/AzuraCast#7668 and feedback from @xogium
Interrupted playback at the end of tracks. Before crossfade buffer starts. Pauses between track transitions (overtime resulting in LS reconnecting to icecast).
It happens with internal autocue, cue_file autocue and basically every other autocue (when it serves as an adapter for other implementations) and crossfade function. So I assume that
crossfadeis a prime suspect.On @unudelaradio stations this issue escalates within 1-2 weeks, on his test instances with 2 short tracks playing back and forth pauses start to appear within few days, eventually resulting in long interruptions. Test stations have
default Azuracast LS configuration.@xogium is experiencing same issue with
minimum script(playlist - autocue - crossfade (add) - output) with issue starting to get noticeable within 1 month.Somehow it correlates with short tracks. More crossfades within a period of time - quicker gaps come into action. Also with
2025/02/20 11:19:11 [request.102033:3] End of track reached at 0.01 before cue-out point at 17.98!messages.As pointed out by @vitoyucepi:
I've asked @xogium to describe the issue as well:
So when using internal autocue plus crossfade, things seem to be quite the mess. It doesn't quite show itself initially, that said. When this happens, it is very gradual. Seems to be in direct corelation with the length of tracks -- the shorter the length, the faster it will degrade the stream.
For example within a month, one of my stream has gotten to the point that:
These are represented as multiple audio underruns in mpv along with complains about things not allowed in the aac stream -- I use fdk aac. The web browsers also don't like this at all, and audacious will display random nonsense error messages about the stream.
On the liquidsoap side, there are a few indications, mention of reaching the end of the track at seemingly random point before the autocue's cue-out point along with a generic clock message about having to catch up x amount of time as well. The catchup time always goes up, and never decreases to none. There's over 3 seconds right now on my stream that is the most affected. But other than this there isn't much to go on.
Version: LS 2.3.0 and later.
Build: doesn't matter. (*.deb package, opam, alpine docker (this is where I've noticed it too))
Steps to reproduce
Expected behavior
Liquidsoap version
Liquidsoap build config
Installation method
From official container image
Additional Info
No response
The text was updated successfully, but these errors were encountered: