Did you change the definition of the card in the spotify connect service file from hw:0 to hw:1? I had to. You can confirm the piano is indeed card 1 by looking at the output of aplay -l
3 Likes
Hi,
Genius !
Many thanks all sorted now
Rene
This is brilliant - thank you, I have been trying to crack this (in vain).
I have not got it to work yet though - can you help? My Linux skills are very limited (basically following instructions!).
I’ve installed as per your instructions on my RPi which is running the HiFiBerry Roon endpoint image. I use a HiFiBerry Digi+ PRO and the image also has Shairport installed.
Installation seemed to go without a glitch, but I’m not sure its running, using:
‘systemctl status spotify-connect.service’ gives:
pi@raspberrypi:~ $ systemctl status spotify-connect.service
● spotify-connect.service - Spotify Connect
Loaded: loaded (/etc/systemd/system/spotify-connect.service; enabled)
Active: activating (auto-restart) (Result: exit-code) since Sun 2017-01-15 11:46:06 UTC; 6s ago
Process: 1248 ExecStart=/root/librespot --name SpotifyConnect --cache /tmp --bitrate 320 --backend alsa --device hw:0 > /dev/null 2>&1 (code=exited, status=203/EXEC)
Main PID: 1248 (code=exited, status=203/EXEC)
‘aplay -l’ gives:
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_digi], device 0: HiFiBerry Digi+ Pro HiFi wm8804-spdif-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
I am assuming when its working the RPi should appear in Spotify (on my Mac) under ‘Devices Available’
Thanks
Douglas
Rene
Update!
Suspecting the culprit was my HiFiBerry Roon Endpoint Image I tried your instructions with a fresh install of DietPi and it has worked flawlessly - thank you.
I will now reinstall the Roon endpoint again and hopefully they will play nicely.
I did rather like the HiFiBerry Endpoint image though - as it rendered an image of the RPi properly in Roon and (it’s probably in my head) it seemed to sound better. I will listen again (using the new DietPi install to see if this is in fact true.
Either way - thanks for your super helpful post.
Douglas
I cannot seem to get Spotify and Shairport to co-exist. I get the following error
avahi client failure
How do I uninstall Spotify?
I think I’ll just put it on a separate SDD for when I need to use it.
.sjb
Following Rene’s instructions I set up my SpotiPi system consisting of a RBPi-2B with HiFiBerry DAC+ and fresh installs of DietPi, Roonbridge and Librespot (1Feb2017).
It works but not flawless. Spotify-connect doesn’t work after powering up the Pi. Roonbridge seems to work fine. Checking the status of spotify-connect.servide gives some errors (a mdns-responder panick and a main panick):
spotify-connect.service - Spotify Connect
Loaded: loaded (/etc/systemd/system/spotify-connect.service; enabled)
Active: active (running) since Fri 2017-02-03 17:03:47 UTC; 3min 50s ago
Main PID: 429 (librespot)
CGroup: /system.slice/spotify-connect.service
ââ429 /root/librespot --name SpotiPi --cache /tmp --bitrate 320 --backend alsa --device hw:0 > /dev/null 2>&1
Feb 03 17:03:47 DietPi systemd[1]: Starting Spotify Connect…
Feb 03 17:03:47 DietPi systemd[1]: Started Spotify Connect.
Feb 03 17:03:52 DietPi librespot[429]: INFO:librespot: librespot 740bee5 (2016-12-30). Built on 2017-01-28.
Feb 03 17:03:52 DietPi librespot[429]: INFO:librespot::authentication: No username provided and no stored credentials, starting discovery …
Feb 03 17:03:52 DietPi librespot[429]: thread ‘mdns-responder’ panicked at ‘called Result::unwrap() on an Err value: Error { repr: Os { code: 19, message: “No such device” } }’, /buildslave/rust-buildbot/slave/stable-dist-rustc-cross-host-linux/build/src/libcore/result.rs:837
Feb 03 17:03:52 DietPi librespot[429]: note: Run with RUST_BACKTRACE=1 for a backtrace.
Feb 03 17:03:52 DietPi librespot[429]: thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: RecvError’, /buildslave/rust-buildbot/slave/stable-dist-rustc-cross-host-linux/build/src/libcore/result.rs:837
After manually executing a roonbridge.service and spotify-connect.service restart, as described in Rene’s post of 7Jan2017, SpotifyConnect is working.
Any ideas where these error messages come from and how I can get my SpotiPi to work directly after start-up without having to restart roonbrdige and librespot services manually?
Thanks,
Oscar
The previous version of Librespot was a bit of spotty as well regarding mDNS. The ‘mdns-responder panicked’ message is new as of the latest version, if I remember correctly. I see the same as you after a reboot – but it is good to see it’s being worked on.
I am now doing the following to circumvent the ‘mdns-responder panicked’ error which causes the spotify-connect.service to fail at system start-up:
At the bottom of the system start-up script (./bashrc) I place the spotify and roonbridge restart. I have no idea what the actual problem is, but this solution works for me. I end with with requesting the status, so that when I login it is the first thing I see.
To enter ./bashrc:
nano /root/.bashrc
Place the following commands at the bottom of the script:
systemctl stop spotify-connect.service
systemctl stop roonbridge.service
systemctl start roonbridge.service
systemctl start spotify-connect.service
systemctl status spotify-connect.service -l
Leave and save:
CTRL-X, y
That’s brutal… But I guess it works.
I just added ‘systemctl restart spotify-connect.service’ – that seems to get the job done.
Any reason for dragging RoonBridge into this? For me, whatever the status of librespot, RoonBridge is fine.
Rene, I was just following the recipe you posted earlier (see above); so doing a restart of both in this particular order. It is good to know that a simple restart of just the spotify-connect.service at the very end of the boot sequence already does the trick. Indeed I am using the latest version of librespot (v20170113-9e495d6).
Unless I’m mistaken, I don’t believe I mentioned anything about needing to stop/restart RoonBridge? They do coexist peacefully, unaffected by one another.
Anyway: my wife will be grateful for your workaround – the times I rebooted the Pi and did not restart librespot manually (of which I was kindly reminded when I returned home again) are behind her now. 
Thanks @RBM for this step-by-step. It worked absolutely perfectly for me. Less than 5 minutes from login to sound. It does peacefully coexist with Roon - the only stipulation is that Spotify must not be playing (or have control of ALSA). Otherwise Roon says it can’t get control of the device. So no hostile takeovers
1 Like
This is annoying, I’ve successfully done this before but my 2 attempts tonight give me the same outcome. I can see a spotify connect option but there is no sound.
seems to be set up okay
root@DietPi:~# systemctl status spotify-connect.service
● spotify-connect.service - Spotify Connect
Loaded: loaded (/etc/systemd/system/spotify-connect.service; enabled)
Active: active (running) since Sun 2017-03-05 23:00:08 UTC; 6min ago
Main PID: 1865 (librespot)
CGroup: /system.slice/spotify-connect.service
└─1865 /root/librespot --name SpotifyPiConnect --cache /tmp --bitrate 320 --backend alsa --device hw:0 > /dev/nul...
Mar 05 23:00:08 DietPi systemd[1]: Started Spotify Connect.
Mar 05 23:00:08 DietPi librespot[1865]: INFO:librespot: librespot 740bee5 (2016-12-30). Built on 2017-01-28.
Mar 05 23:00:08 DietPi librespot[1865]: INFO:librespot::session: Connecting to AP lon6-accesspoint-a22.ap.spotify.com:4070
Mar 05 23:00:08 DietPi librespot[1865]: INFO:librespot::session: Authenticated !
Mar 05 23:00:08 DietPi librespot[1865]: INFO:librespot::audio_backend::alsa: Using alsa sink
Mar 05 23:00:14 DietPi librespot[1865]: INFO:librespot::player: Loading track "Goldfisch"
Mar 05 23:00:14 DietPi librespot[1865]: INFO:librespot::player: Load Done
Any ideas?
.sjb
I’ve isolated the issue to the fact that the connection is USB.
I’ve tried the SD card in another Pi with hifiberry digi+ and it worked fine.
Is there a known issue with USB or si there anything I can do?
thanks
.sjb
@Sloop_John_B: Could it be that your USB device is on a different hardware number? What does ‘aplay -l’ say?
(If it is, you should probable change ‘–device hw:0’ to ‘–device hw:1’ in the service definition).
Thanks @RBM , I actually did think of that and tried it but still no luck.
I think I’ll have to have another go, maybe with all my fapping I broke some other part of it.
Just to be sure here is aplay
List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_digi], device 0: HiFiBerry Digi+ Pro HiFi wm8804-spdif-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: HugoTT [HugoTT], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
So I now need the following?
backend alsa --device hw:1 > /dev/null 2>&1
I’ll try it again this evening.
Thanks
.sjb
Took a bit of fiddling, but I think I’m there: it appears librespot is not too happy about ALSA opening USB hardware directly. A workaround is to use ‘plughw’ instead of ‘hw’.
Find your correct ‘card’ by issuing ‘aplay -L’ (capital L this time). On my Cubox, the one I’m looking for is listed last (Chord Mojo USB DAC; yours will differ):
plughw:CARD=Mojo,DEV=0
Mojo, USB Audio
Hardware device with all software conversions
In the service definition file, change ‘–device hw:1’ to ‘–device plughw:CARD=Mojo’ (change Mojo to whatever is listed through ‘aplay -L’ for your DAC. You can leave out the ‘,DEV=0’.
Then, issue:
systemctl daemon-reload
systemctl restart spotify-connect.service
Let me know how it goes!
2 Likes
I have been using the device name rather than number from the start. You don’t need the “CARD=” either. So in your case it would be “plughw:Mojo”
2 Likes
Top marks 
once again Rene, worked like a charm.
.sjb
1 Like