"Buffer overrun" and "we must catchup" when migrating from Centos 7 to Debian 10.9 and a newer liquidsoap

[namebee]

Describe the bug
We've been trying to migrate from CentOS 7 to Debian 10.9, But are having issues with the exact same script being used on a newer Liquidsoap on Debian 10.9. Both VM's are on the exact same host, Have the exact same amount of CPU and ram.

On Debian Buffer overrun: Dropping 0.02s. Consider increasing the max buffer size! and [clock.wallclock_main:2] We must catchup 4.66 seconds! with the last error (the clock one) keeps counting up slowly until the buffer overrun message starts being spammed.

The script looks like this:

set("harbor.bind_addr","0.0.0.0")

def_playlist = playlist("/home/icecast/redacted/fallback")
radio = random([def_playlist])

redacted_live = audio_to_stereo(input.harbor("redacted",port=8694,password="redacted"))
redacted_full = fallback(track_sensitive=false, [redacted_live,radio])
output.icecast (%mp3.cbr(bitrate=192, samplerate=44100, stereo=true, internal_quality=0, id3v2=true),
                redacted_full, mount="redacted", host="0.0.0.0",
                port=8690, password="redacted", fallible=true)

Only with there being about 8 outputs with different harbor inputs instead of one. I am thinking about downgrading Liquidsoap and then trying that.

I hope I provided a good title and enough info.

To Reproduce
I don't think I can fill in anything here

Expected behavior
A clear and concise description of what you expected to happen.

Version details

• OS: Debian 10.9 and Centos 7
• Version: 1.4.4 and 1.3.7

Install method
On the Debian machine it was installed via the .deb file on the Releases page, I can't remember on Centos.

[martinkirch]

Hello,
This message happens when a source (typically input.harbor or input.http) is streaming without being consumed by an output.

you mentioned

Only with there being about 8 outputs with different harbor inputs instead of one

That's a clue ; maybe the combination isn't working as expected. However it will be hard to help without the complete script.

Also, the log should mention the problematic source's ID. You can assign id="some_unique_name", with a different ID, to each of your sources/outputs/operators, so the log will suggest more clearly which one is over-buffering.

[toots]

Hi! Have you checked the CPU usage? Another cause for these issues is if your machine cannot handle 8 encoding at the same time. It's possible we might have an issue with increased CPU usage in most recent versions?

[namebee]

Hi! Have you checked the CPU usage? Another cause for these issues is if your machine cannot handle 8 encoding at the same time. It's possible we might have an issue with increased CPU usage in most recent versions?

The CPU usage on the Debian machine is way higher than on the Centos 7 machine (especially in the "spiking" it does).

I'll have to check what the other person mentioned. If that doesn't help I'll try the Liquidsoap version the Centos 7 machine is on.

[namebee]

Hello,
This message happens when a source (typically input.harbor or input.http) is streaming without being consumed by an output.

you mentioned

Only with there being about 8 outputs with different harbor inputs instead of one

That's a clue ; maybe the combination isn't working as expected. However it will be hard to help without the complete script.

Also, the log should mention the problematic source's ID. You can assign id="some_unique_name", with a different ID, to each of your sources/outputs/operators, so the log will suggest more clearly which one is over-buffering.

It seems that basically every single harbor input is having buffer overrun issues, I think I'm just gonna try to go to the exact same Liquidsoap version the Centos 7 machine is on.

[toots]

Ok. If you're feeling like it, we have support for shared encoding in liquidsoap 2.0, that could also solve your issue.