Pipe backend not working
timglong opened this issue · comments
Compatible OS
- I'm running Raspotify on a compatible OS
Latest Version
- I'm running the latest version of Raspotify
Due Diligence
- I have done my due diligence
What happened?
I'm not having any luck using the pipe backend. I found and read #458 and #468, read the wiki entry and changed LIBRESPOT_DEVICE to /var/run/snapfifo, but it seems Raspotify can't write to the locations specified. Using LIBRESPOT_DEVICE="/var/run/snapfifo" gives me an os error 30 and I either receive an os error 2 or an os error 30 if I point at/create a new folder inside /var/run/.
Jan 16 15:45:02 PiOffice librespot[796]: [2022-01-16T21:45:02Z ERROR librespot_playback::player] Audio Sink Error Connection Refused: Read-only file system (os error 30)
Jan 16 16:08:38 PiOffice librespot[858]: [2022-01-16T22:08:38Z ERROR librespot_playback::player] Audio Sink Error Connection Refused: No such file or directory (os error 2)
Previously I was using BACKEND_ARGS="--backend pipe --device /tmp/snapfifo" and this worked very nicely.
After the change I'm using LIBRESPOT_BACKEND="pipe" and LIBRESPOT_DEVICE="/var/run/snapfifo" as described above.
This is a brand new Bullseye install and a brand new Raspotify install on a Pi4. I'm hoping I'm just missing something simple as I was looking forward to playing around with some of the new options.
Relevant log output
Jan 16 16:39:56 PiOffice systemd[1]: Started Raspotify (Spotify Connect Client). Jan 16 16:40:03 PiOffice librespot[1022]: [2022-01-16T22:40:03Z ERROR librespot_playback::player] Audio Sink Error Connection Refused: Read-only file system (os error 30) Jan 16 16:40:03 PiOffice systemd[1]: raspotify.service: Main process exited, code=exited, status=1/FAILURE Jan 16 16:40:03 PiOffice systemd[1]: raspotify.service: Failed with result 'exit-code'.
Ok, stupid question:
Have you configured snapcast to put it's fifo in /var/run?
As far as I'm aware, yes. I'm not super familiar with the workings of pipe/fifo, but it sounds like the creation of the connection is NOT being handled by Raspotify, so maybe I'm directing my question to the wrong place.
That seems like a very reasonable question!
As far as I'm aware, yes. I'm not super familiar with the workings of pipe/fifo, but it sounds like the creation of the connection is NOT being handled by Raspotify, so maybe I'm directing my question to the wrong place.
That seems like a very reasonable question!
If you don't know for sure if you've configured snapcast to create the fifo in /var/run you probably haven't. That's not it's default location. You can look at the config file changes in this PR for clues as to what you should change on the snapcast side:
I shouldn't have qualified the statement--yes, Snapcast and Raspotify are pointing at the same fifo and I've configured snapcast to put the fifo somewhere other than /tmp/. I've tried a number of different locations for the fifo; in all but the original /tmp/ location, Snapcast fails to create the fifo. Raspotify will not read the fifo in the /tmp/ location.
The code linked above appears to be using earlier versions of both Raspotify and Snapcast, and the conf modifications don't work, at least in my situation.
From badaix/snapcast#737, running sudo sysctl -n fs.protected_fifos returns 1 on the Pi that was just updated to Bullseye and 0 on a client running Buster. I haven't tried the workaround listed there yet. badaix/snapcast#486 also seems relevant.
I'm not sure how to proceed.
Edit: nevermind, the below works right up until you reboot and the fifo is deleted.
Some progress after reading up on fifos--I now have (garbled, distorted) sound!
What worked was creating the fifo manually, modifying permissions so Raspotify can write to it, and changing the pipe behavior in snapcast from read to create.
In
/run/snapserver/create the fifo withsudo mkfifo snapfifo. Runningls -l /run/snapserverprovides the followingprw-r--r-- 1 root root 0 Jan 17 08:34 snapfifoand Raspotify errors out as expected (can't write to file).Set write permissions using
sudo chmod go+w /run/snapserver/snapfifoso Raspotify can write to the fifo.Modify the snapserver conf file with
&mode=readlike sosource = pipe:///run/snapserver/snapfifo?name=Spotify&sampleformat=44100:16:2&mode=read, ensure Raspotify is pointing at the same location, and we've achieved sound.Now I'll try to determine what's going on with the garbling/distortion.
I'm not a snapcast user but I installed it to see what I could come up with and I get the same results. They've known that /tmp is not a good place for a fifo for over 2 years.
I notice references to alsa in the config. Maybe you could investigate that?
In any event this is a snapcast issue not a Raspotify issue so I'm closing this issue.
Ok, stupid question:
Have you configured snapcast to put it's fifo in
/var/run?
why is /var/run recommended? it gets cleared on reboot.
why is /var/run recommended? it gets cleared on reboot.
/tmp gets cleared pretty often too automatically.
http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-directory-1219006.html
My understanding is that /run (which is what /var/run links to) is supposed to be a tmpfs for apps to store things they need to run. (hence the name I guess?) in the case of snapcast it means that they would need to create the fifo when the service 1st started at least once after each boot.
I don't make the rules. I'm just following best and current practices.
Makes sense. Thanks 👍
If anyone figures this out, please let me know. The snapcast folks don't seem to care, so for the time being I'm going to revert to Raspotify 0.16 or I guess figure out how to build/configure librespot on my own. It was a good year of multi-room audio, RIP.
If anyone figures this out, please let me know. The snapcast folks don't seem to care, so for the time being I'm going to revert to Raspotify 0.16 or I guess figure out how to build/configure librespot on my own. It was a good year of multi-room audio, RIP.
You don't have to revert. In a pinch if all else fails (with a little effort and some trial and error) you can disable the Raspotify service and write your own systemd service file and use the librespot binary packaged with Raspotify. Remember Raspotify is just a compiled binary, a systemd service file and a config. There's nothing stopping you from using the binary however you like.
@JasonLG1979 I think the best way to handle this moving forward is to just not use pipe--I was able to get my system back up and running by using librespot directly, just like you suggested. Maybe we could add this to the wiki?
Here's the snapserver conf line for my setup, including all the parameters I usually set with Raspotify:
source = spotify:///usr/bin/librespot?name=Spotify&username=***&password=***&devicename=***&bitrate=320&wd_timeout=7800&volume=100&normalize=false&autoplay=false&disable_audio_cache=true¶ms=--device-type%20avr¶ms=--volume-ctrl%20fixed¶ms=--format%20S32¶ms=--disable-discovery%20true
The nice thing about this is you can use the params argument to add any options from librespot very easily.
Edit: no writing of anything (beyond the source line) is necessary, Raspotify has already installed librespot, you just have to point snapcast at librespot instead of the pipe/Raspotify.
Don't forget to disable the raspotify service unless ofc you want 2 instances of librespot running?
I'd love to see this in the wiki. Feel free to add a page about snapcast integration.
To disable it's just sudo systemctl disable raspotify, right?
I want to do a bit more testing but once that's done I will make a wiki post.
Yep.
Sounds good.
This is an upstream issue. You should file an issue with librespot.