DietPi Squeezelite players with same MAC address 00:00:00:00:00:00

I have 2 RPI’s with DietPi and Squeezelite running as LMS music players. When I moved my Logitech Media Server from a dedicated RPi to a new, more powerful, Home Assistant mini-PC, I noticed during testing that both players got the same 00:00:00:00:00:00 MAC address and therefore caused issues. I first thought it was the new server, but when I tried the old one again, the same problem occurred. Maybe I never noticed because I never have these 2 players on at the same time, or maybe it is caused by a recent update.

Nevertheless, after searching the internet for many hours and trying different things, I found the solution;
Apparently squeezelite.service was already started before a network connection was established. I somewhere found a suggestion that in Systemd squeezelite.service under [Unit] the After= should have network-online.target instead of network.target. When I wanted to edit it, I noticed that there was After=sound.target in the squeezelite.service installed trough DietPi-software. Changing that to network-online.target fixed the MAC address issue and both returned to the standard device MAC addresses.

Is there a specific reason why there was the sound.target used? Could I expect other issues? Is there a way to use both and should I do that?

I don’t know why sound.target is used, but here is how you can set multiple unit names:
https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Before=

Before=, After=

    These two settings expect a space-separated list of unit names. 
They may be specified more than once, in which case dependencies for all listed names are created.

@Jappe, thank you for the link. I don’t know much about these things, not a developer nor a programmer. If anything, maybe a superuser who can follow instruction and search the net for more instructions when having issues….

I suspect sound.target is there so Squeezelite doesn’t start before a soundcard is detected and available. That could be a good thing to have in there, I suppose. From the information you provided I learn that you can have more “space-separated” unit names in there, so I’ll give that a try. Thanks.

Maybe @MichaIng could have a look into the suggestion to add network-online.target as we build squeezelite ourself.

@Joulinar That would be a great plan. I saw this issue mentioned a few times, only with different solutions, like forcing some MAC address through an argument in a Squeezelite configuration file. That, however, didn’t work in my case.

Following up on my earlier reply, I tried putting inAfter=network-online.target sound.target
but that didn’t make Squeezelite wait for and start after the soundcard was turned on. One of my DietPi players uses a USB-DAC which I normally turn on before the RPi. In this test I turned on the RPi first and waited a bit. Then I turned on the USB-DAC but nothing happened. I could then start Squeezelite through DietPi-Dashboard. That leads me to conclude that sound.target doesn’t do what I expected; starting Squeezelite when the sound device is available. Probably other things, that I’m not aware of, play a role here…

Hmm, Squeezelite identifies itself among LMS servers via MAC address? I thought it identifies itself with the name added via -n CLI argument, which we set to “DietPi-Squeezelite” by default. See etc/default/squeezelite.

I mean having it starting strictly after all network interfaces have been configured, does not really hurt, since local LMS starts after network as well, and remote LMS cannot connect before network is up anyway. I just avoid unnecessary dependencies/ordering to enhance parallelisation on boot, and Squeezelite does not generally have issues to start before network is up, like other web applications which bind to a network port, as it listens unconditionally on some random high UDP port.

Add another line:

Wants=network-online.target

This is an active target, hence is not pulled/started at boot automatically, and not pulled in by services which “provide” network, but must be pulled in by any service which wants to order itself after it/depend on it.

Thanks for looking at this. I don’t know much beyond maybe superuser level about the inner workings of these things, but it seems MAC address plays an important role since when I use multiple DietPi players in LMS and both get 00:00:00:00:00:00 as MAC address things go crazy. I did see in settings in Squeezelite (made visible by a PiCorePlayer interface page) that you have the option to set your own MAC address in Squeezelite settings. I tried this as well in DietPi but didn’t lead to a solution. I did change the -n argument, the player name, for each player in their Squeezelite settings. That name is used to select the player in the webinterface.

Do you want me to add the line, or change it like this?

After=sound.target
Wants=network-online.target

Like this:

Wants=network-online.target
After=network-online.target sound.target

@willefg
Let me know whether this helps, so I will merge this into our build script as well. Now I need to do some Raspberry Pi 2 photo shooting for the DietPi release notes :star_struck:.

2 Likes

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.