Volumio Version: 2.882
Hardware: Raspberry Pi4 8GB
DAC: Schiit Asgard 3 w/ Multibit DAC
Hello Everyone,
New user with a fresh install. I have Spotify listed as “On” under Sources / Sources Visibility.
Steps to recreate my issue.
If logging in is the issue, is there a way to get it to login automatically? I don’t mind ssh’ing to the box if needed.
Yes a system log would be very useful. Do exactly what you specify above and then post link to system logs here.
Thanks, here is a copy of the logs after I did the steps above.
Again Spotify listed as a source after reboot. After going to plugins and logging back in again it works.
bump
Any ideas what could be causing this?
The log shows that Volumio is unable to connect to Spotify initially, but doesn’t give any details other than:
Jul 19 23:34:03 asgard volumio[977]: 2021-07-19 23:34:03 [ERR ] Can’t bind socket: Cannot assign requested address
Jul 19 23:34:03 asgard systemd[1]: spop.service: main process exited, code=killed, status=5/TRAP
Jul 19 23:34:03 asgard systemd[1]: Unit spop.service entered failed state.
As you say, the connection works fine later when you login manually. I can’t reproduce this on my devices, and I haven’t seen it reported elsewhere. You should try removing & reinstalling the plugin, but other than that you’ll have to wait for one of the devs to chip in to the thread (note that many people are away on holiday during this period).
Are you sure you’re not using an account that already is registered or even open on another device?
Make sure to check this @spotify.
Thanks I’ve already done a fresh install and even installed and re-installed. Wonder what interface its trying to use to do that bind request. Another device shouldn’t matter for a local bind to a socket. I can ssh to the device and play around I guess.
Thanks for the suggestions. I ended up figuring out the issue that was causing Spotify to fail on boot.
I enabled SSH and went through the logs with after a fresh install. Its the sequence of events, that is causing an issue for the Plugin. Something that should be addressed, but I have a workaround. All my interfaces but eth0 is enabled (meaning I disabled wifi which is its default for connectivity). The device starts the plugin before DHCP can reach out and request an IP address. You can see the Spotify Plugin trying to connect but the interface hasn’t been fully initialized. This explains why asking it to login after boot works.
Workaround assigned it a STATIC IP on eth0.
Reboots with no issues
Glad you’re sorted…it was a bit of a head scratcher, and not knowing your local setup makes things difficult.
Does it help adding the following to the spop service file?
After=network-online.target
Wants=network-online.target
Wouldn’t come with that one. thanks for the logs.
This should actually not be needed, as this is already part of “/lib/systemd/system/dhcpcd.service”
If you want an improved version, please look at:
https://www.raspberrypi.org/forums/viewtopic.php?t=187225
Are you sure? This is what I see – sysmtemd will launch this when syslog is ready, not caring about any network stuff…
# \lib\systemd\system\spop.service
[Unit]
Description=Spotify Daemon
After=syslog.target
[Service]
Type=simple
Environment=LD_LIBRARY_PATH=/usr/local/lib
ExecStart=/usr/bin/spopd -f -c /etc/spopd.conf
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=volumio
User=volumio
Group=volumio
[Install]
WantedBy=multi-user.target
FWIW: syslog.target is also probably outdated in not needed…
@ashthespy same issue, had to go back to a static IP.
Thats not the content of /lib/systemd/system/dhcpcd.service
This is the content of /lib/systemd/system/dhcpcd.service:
[Unit]
Description=dhcpcd on all interfaces
Wants=network.target
Before=network.target
[Service]
Type=forking
PIDFile=/run/dhcpcd.pid
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b
ExecStop=/sbin/dhcpcd -x
[Install]
WantedBy=multi-user.target
Alias=dhcpcd5.service
My response is to do with the spop.service i.e the service file for the Spotify daemon. I am not sure why the contents of dhcpcd.service would be relevant here, as my suggestion was to wait until the network was up and running and only then starting the daemon.
Either way, it’s all moot if it doesn’t work…
Does it still give you the same socket bind error? It then might be something else.
But yeah, if you found something that works for you, no reason to dig deeper 
yep, I noticed that.
I am just giving a global solution, not on plugin level. If you go that way and have more plugins or services that need a network connection alive, it becomes difficult to maintain. Just a matter of opinion.
I am not following – how would you solve this at a global level?
Each service needs to identify for itself if it depends on a fully ready network or not.
systemd is quite powerful, but I don’t think it does any scanning/automagic determination if a particular service requires the network or not?
How should it determine if your service requires the network from the dhcpcd.service you linked?
Either way, however it’s solved, it’s much better than adding a hardcoded delay!
If you are more curious about how systemd handles dependency chains, try running systemd-analyze critical-chain or systemd-analyze plot >volumio_boot.svg to analyse of how service chains are managed.
Currently Volumio doesn’t utilize systemd very well, but this should be improved going forward if you ask me…
@Wheaten and @ashthespy,
Okay, so I maybe new to Volumio, but not to OpenBSD, Linux, and UNIX 
@ashthespy was on the right path and here is the solution that should work for everyone. If you like please feel free to use it. This was tested on a fresh install, with several reboots and no failures.
Couple Issues that need to be fixed, if it was me.
$ cd /lib/systemd/system
## (shouldn't be executable)
$ chmod 644 spop.service
##(setup the terminal)
##(edit spop.service -- no vi, so lets use pico)
$ export TERM=vt100;
$ pico spop.service
(remove syslog.target, not needed if muli-user and networking is up syslog should have been up long ago)
ADD:
After=systemd-networkd-wait-online.service
Wants=systemd-networkd-wait-online.service
## SAVE
$ systemctl enable systemd-networkd.service systemd-networkd-wait-online.service
Now reboot and your Spotify should wait for an ip address Also for DHCP make sure your timezone is set correctly. I noticed mine wasn’t but that’s a quick fix at the cmd line.
Enjoy!
Useful info, thanks @BigManz. Systemd is very powerful, and is not always optimised in service files…I have had several problems on my main PC with actions falling because of network not being fully up, for example.
Timezone setting is an old favorite…easy to fix, but low down on priority. 