Open TomKranenburg opened 9 months ago
Hi @TomKranenburg, Could you share the info about your system?
Hi @TomKranenburg, Could you share the info about your system?
- What operating system do you use?
- How did you get liquidsoap? Docker, packages, opam or something else?
- What version of liquidsoap are you running?
- How did it look in the logs?
Sorry @vitoyucepi. I should know better. This should have been in my original post.
I am running it on Windows 10. I'll migrate the config to a Linux system later.
Precompiled binaries @ https://github.com/savonet/liquidsoap/releases/download/v2.2.4/liquidsoap-2.2.4-win64.zip
v2.2.4
Nothing in the logs my good man. That's why I'm reaching out really. I think if my setup is correct I'm printing the log to stdout anyway? I see nothing when it fully crashes sadly.
I'll add that the music files are being accessed via liquidsoap over an SMB share. I do wonder if that's part of the problem. In the logs I'm getting a lot of things like this:
2024/03/04 17:39:43 [clock.main:2] We must catchup 5.16 seconds!
This is generally when the skips occur I think.
I will add as well. I'm getting a lot of:
[mp3 @ 000001b3d2ed7840] Estimating duration from bitrate, this may be inaccurate
This is going to be a problem I think as a lot of my MP3s are VBR.
Thread about it here:
Looks like it's down to ffmpeg.
Could you verify that the problem is present in rolling-release-v2.2.x
?
You can download the binaries from the release page.
v2.2.4
There's a problem here, there are two versions 2.2.4 and 2.2.4-1.
I think if you run liquidsoap.exe --build-config
, it will print all the necessary information.
Also, right after the start liquidsoap will print long line with the libs versions, you could post it instead.
[mp3 @ 000001b3d2ed7840] Estimating duration from bitrate, this may be inaccurate
You can't calculate the exact duration just by closely looking at the file, you have to decode the whole file. So I think this is not a problem.
Ok here is the liquidsoap.exe --build-config
output:
Do you have files with umlauts in your playlist and are your playlists UTF-8 encoded? If not - try to encode them as UTF-8.
Do you have files with umlauts in your playlist and are your playlists UTF-8 encoded? If not - try to encode them as UTF-8.
They are UTF-8 for sure. I think there this no umlauts. I try to stick to ASCII for file names. There will be non ASCII in the MP3 tags I'm sure of it.
Thanks for the report. More details about the crash would help. Are you getting any log at all?
We have tracked down segfaults in the ffmpeg code when opening files that have non-utf8 characters on windows. Can that be linked? Also, have you tried without samba in the mix?
Thanks for the report. More details about the crash would help. Are you getting any log at all?
We have tracked down segfaults in the ffmpeg code when opening files that have non-utf8 characters on windows. Can that be linked? Also, have you tried without samba in the mix?
Perfect timing.
Actually yes I did try it without Samba in the mix. I created a system that copies every single track to a local SSD to see if that could help. Anticipating access times on a network file system must be a horror show.
However it changed absolutely nothing in the slightest. I should add that the time it has to catch up is almost always around 5.15 seconds. It's pretty consistently close to this if that helps. Here's some excerpts:
2024/03/09 07:20:42 [clock.main:2] We must catchup 5.15 seconds!
2024/03/09 07:24:20 [clock.main:2] We must catchup 5.18 seconds!
2024/03/09 07:26:08 [clock.main:2] We must catchup 5.18 seconds!
2024/03/09 07:32:32 [clock.main:2] We must catchup 5.13 seconds!
2024/03/09 07:33:58 [clock.main:2] We must catchup 5.16 seconds!
We have tracked down segfaults in the ffmpeg code when opening files that have non-utf8 characters on windows. Can that be linked?
It could be. Only the file names are clean, the actual metadata will have all kinds of non standard characters. There is nothing in the log. From my perspective it's a silent fail. But next time it tanks I'll make a note of the file names queued and see if they have any odd metadata. I'll then update here.
Thanks for this. As a software package I think liquidsoap is great. I'm not giving it up.
I just want to add,
I actually upgraded the CPU on this system without reinstalling the OS. I felt this was a risky manoeuvre personally. Many will fight me on that however and say it's totally fine. So far there have been no issues for months but this could be the first one couldn't it.
Just wanted to add that as the time lag there is unusually consistent.
Can anyone take a quick look over this config? The crashes have no error message sadly. So I don't know where to start when it comes to debugging: