LS restarting after crossfades - sporadically

[fkane]

Just posting this in case it helps anyone else. I've run into this behavior in both LS 2.2.5 and 2.3.0 running on Ubuntu 24.04.01 (built from opam), where once every few hours, once a day... it's hard to predict... the script will restart for no apparent reason. There's nothing in the logs indicating an error, even at level 4 - it just shows that everything was going fine, and then the service restarts. From a listener standpoint, they are disconnected when this happens as the existing streams are stopped and restarted. The only pattern I've found is that it usually happens a few seconds after a crossfade transition.

In my case, I think it was just taxing my EC2 server a little too hard. Upgrading from a t3.medium instance to a t3.large did not help matters, though.

What finally did seem to help was reducing the sample rate conversion quality. I stream at 24-bit / 48kHz from hi-res sources, so this is a bit of a CPU hog. I've been running successfully now after commenting out these lines in my script:

#settings.audio.converter.samplerate.libsamplerate.quality.set("medium")
#settings.audio.converter.samplerate.native.quality.set("linear")

...thereby going back to the default "fast" setting. My ears can't tell the difference.

Anyhow, if you've bumped up your sample rate quality settings and are wondering why your server keeps restarting after updating LS beyond 2.1.x... that might be why.

[vitoyucepi]

Hi @fkane,
Would you mind creating a new issue? If you do, please collect build configs from both 2.2.5 and 2.3.0.
It would be beneficial if you could take a look at the exit code of the liquidsoap process after a crash. It may be a random ocaml GC segfault or something else, so I also recommend getting a gdb trace.

New process

% gdb /path/to/liquidsoap
> r <arguments>
...crash..
> thread apply all bt

Running process

% gdb -p <liquidsoap process PID>
> thread apply all bt

[gAlleb]

There has been a problem not so while ago preventing internal autocue work when we have mixed sample_rate/sample_format content. It just crashed or went to silence. Without anything useful in the logs.

E.g. sample_rate=44100,sample_format=s16 and sample_rate=192000,sample_format=fltp (or it may be s32, doesn't matter).

Sometimes it showed such phrases during cross:

[decoder:2] Error while checking file's content: Content.Incompatible_format: formats
 ffmpeg.audio.raw(sample_rate=44100,sample_format=s16,channel_layout=stereo) and 
ffmpeg.audio.raw(sample_rate=192000,sample_format=fltp,channel_layout=stereo) are incompatible!

Toots has fixed it. Maybe it is somehow connected.

[fkane]

FWIW, the word "incompatible" does not appear in my logs at all (although my sources are a variety of rates and formats).

Unfortunately it did happen again once overnight last night, so reducing the samplerate quality settings wasn't a fix after all.

There's no indication of an actual crash in the logs, no core dump or anything to examine, no exit code, no mention of a segfault, nothing. So I'm afraid there's not much to go on. The current track just stops prematurely, and then the logs indicate everything starting back up from scratch.

My instance with 2.2.5 has been deleted so all I can offer is the build config for 2.3.0. I'll file what little info I have in an issue, though.