Solved: squeezelite quitting on RPi

Troubleshooting
1

I found that the problem described below could be easily cured simply by uninstalling the current squeezelite version built into DietPi 6.33.3 and replacing it with the most recent version from GitHub. That version - v1.9.7-1283 - is built with these options:

LINUX ALSA EVENTFD RESAMPLE ALAC OPUS VISEXPORT IR GPIO RPI DSD SSL LINKALL

Again, this difference applies to an RPi 3B+ and prevents frequent random crashes.

…hope the supported DietPi version squeezelite will be updated soon so others don’t have to dink with this…

Best,

Frank

Original post:

Greetings,

I would greatly appreciate any suggestions to solve problems with squeezelite on a new rig with DietPi version 6.33.3 running on a RPi 3B+, and LMS on a RPi 4.1. Never any problems with the same LMS working into other older squeezelite versions, but the current 1.9.7-1260 is acting up. I need to restore it using ‘service squeezelite restart’ every few minutes.

Process: 883 ExecStart=/usr/bin/squeezelite -a 4096:1024:32:0 -n Largo Audio (code=killed, signal=ABRT)

Here is the current setup:
State : [failed]
Mode : [DietPi controlled]
Include/Exclude : [included]
CPU Affinity : [3]
CPU Scheduling Policy : [fifo]
CPU Scheduling Priority : [80]
I/O Scheduling Class : [realtime]
I/O Scheduling Priority : [0]

Here are top entries from the service.d log:
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.185530] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.188280] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.290993] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.393756] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.496912] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.597109] ffmpeg: Invalid return value 0 for stream protocol
Nov 18 06:23:13 DietPi squeezelite[883]: [06:23:13.597259] ffmpeg: Invalid return value 0 for stream protocol
Nov 18 06:23:13 DietPi squeezelite[883]: double free or corruption (fasttop)
Nov 18 06:23:13 DietPi systemd[1]: squeezelite.service: Main process exited, code=killed, status=6/ABRT
Nov 18 06:23:13 DietPi systemd[1]: squeezelite.service: Failed with result ‘signal’.

Thanks for any and all help!

Frank

2

A bit more info -

Sourcing a second LMS server with very good throughput, the same errors occur. They don’t seem dependent on midia file type. They can happen at any time, but often seem to coincide with when the end of a media file is reached or with any action that terminates media transfer to begin transfer of a different file. They seem to happen with equal probability regardless of the network settings and CPU priority. However, limiting output to 16 bits does seem to keep the crashes farther apart in time.

I see on the piCore site that they use a build option called RPi - anybody know what that’s about? Ralph Irving’s GitHub makefile documentation for RPi (15 months old) does specifically include an option named ‘-DRPI’.
https://github.com/ralph-irving/squeezelite/blob/master/Makefile.rpi
I wonder why that is not used in the DietPi version…

Again, all insights greatly appreciated…

Frank

3

Many thanks for sharing your solution. DietP is using own compiled packages for Squeezelite and they are from mid of this year. I guess they are created by MichaIng. Maybe he can give some inside what options are used.

4

The “RPI” built option enables some GPIO feature only, i.e. those two files are built and included:

We don’t build it with GPIO support currently, until someone explicitly asks for, since it would complicate the build and ship procedure when we need to spit device-specific builds instead of, as currently, only arch-specific builds :wink:.

So at least that flag has nothing to do with the error you face, but probably another change upstream chance since our build is related. I’ll rebuild it. Here the options I use btw: OPTS=’-DDSD -DFFMPEG -DRESAMPLE -DVISEXPORT -DLINKALL -DIR -DUSE_SSL’
I.e. FFmpeg can handle OPUS and ALAC instead of adding their standalone libraries. When using dedicated OPUS and ALAC support, you needed to install libopus-dev for sure, but did ALAC work OOTB? I’ve just seen this discussion in the quite recent implementation of those and though that staying with previous FFmpeg would be safer for now: https://github.com/ralph-irving/squeezelite/issues/104

5

francolargo
Could you test the new build:

cd /tmp
wget https://dietpi.com/downloads/binaries/buster/squeezelite_armv7l.deb
apt install ./squeezelite_armv7l.deb
rm squeezelite_armv7l.deb
6

Sorry to have not replied re squeezelite. I rarely come here - when all is working there is no need! :wink:

I just did a clean rebuild on a fresh uSD card and found that squeezelite service could use some attention. When I try to change the -a settings of “4096:1024:16:0:0” by editing the squeezelite.service drop-in I get:

squeezelite.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.

To make my prefered settings work I need to manage the squeezelite service using systemd rather than squeezelite, and edit /usr/lib/systemd/system/squeezelite.service. I would prefer that the drop-in work, but it reports a ‘bad unit file setting’. Meanwhile the systemd workaround is OK.

Your squeezelite -a settings format everything at 16 bits and this really crimps the quality of “HD” sources with greater bit depth. For years I have used " -a 4096:1024::0:0" and never a problem in several different systems. The high resolution files play fine and the 16 bit stuff plays fine, whether output is I2S or USB.

Thanks for your work and diligence maintaining dietPi!

7

Side note: I had a similiar issue while editing a service via dietpi-service and the workaround was to set a single line ExecStart= before the actual ExecStart=HERE_COMES_SOMETHING.

See: Papermc.service: Failed with result 'exit-code' - #3 by Jappe

8

the workaround was to set a single line > ExecStart= > before the actual

btw: this is not a workaround, this is must have :wink:

9

But it was not working with this:

...
#WorkingDirectory=/mnt/dietpi_userdata/papermc
ExecStart=/usr/bin/java -Xms1g -Xmx2g -jar /opt/papermc/paperclip.jar --nogui --noconsole
...

But was working with this:

...
#WorkingDirectory=/mnt/dietpi_userdata/papermc
ExecStart=
ExecStart=/usr/bin/java -Xms1g -Xmx2g -jar /opt/papermc/paperclip.jar --nogui --noconsole
...

And when I look into a “normal” working config, which was not modified via dietpi-services, there is no

ExecStart=
ExecStart=SOMETHING

I thought I understood what was the problem then, but now I’m confused :smiley:

Or maybe I expressed myself not well enough: He just needed this one line instead of editing the actual service config?!

10

maybe we misunderstood each other. I was playing on words. Your statement was, adding an ExecStart= would be a workaround. Thie means, to work around an issue. But it is not working around an issue, it is actually the real solution. It is needed to overwrite/reset the ExecStart= command from the original configuration line. Therefore it is a must have :smiley:

11

Jep, the drop-in config is “added” to the original config, so just setting “ExecStart=” means there are two “ExecStart” entries, which is not allowed for this type of service. So the drop-in config first needs to unset the original “ExecStart=” by setting it empty, then it can assign a new command. A bit annoying, as systemd might be able to do this internally for such service types, but it currently requires to be so explicit. Other services types (like “Type=oneshot”) allow multiple “ExecStart” commands.

12

I got you!