Error 6 on opening pipe: "No such device or address".

jgabriel98 commented 4 years ago

i've been trying to use the pipe backend for shairport, so i can read it with SnapCast-server. But, no matter what configuration i always get the following error on systemctl status shairport-sync.service: Error 6 opening the pipe named "/tmp/snapfifo_shairport": "No such device or address".

what i've already tried:

let the shairport create the pipe, then let the snapcast create it
let the snapcast create the pipe, then let the shairport create it
run shairport as a system service
run shairport as a user (non root) process
set the pipe path to an user access local, like '/home/pi/shairport_fifo'

i am currently running on a raspberry pi 4, running rapberry OS (before named raspbian)

mikebrady commented 4 years ago

Thanks for the post. I have just tried the same thing with the latest version of Shairport Sync and I'm afraid I can not reproduce the issue. Perhaps you'd let us have some more information about your system?

jgabriel98 commented 4 years ago

Sure, sorry for not giving that information from the very start. Here it goes

$ shairport-sync -V:

3.2.2-OpenSSL-Avahi-ALSA-pa-dummy-stdout-pipe-soxr-convolution-metadata-sysconfdir:/etc

sudo systemctl status shairport-sync:

● shairport-sync.service - ShairportSync AirTunes receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-07-10 00:04:06 -03; 12h ago
     Docs: man:shairport-sync(7)
           file:///usr/share/doc/shairport-sync/README.md.gz
           https://github.com/mikebrady/shairport-sync
 Main PID: 8607 (shairport-sync)
    Tasks: 3 (limit: 4915)
   Memory: 3.0M
   CGroup: /system.slice/shairport-sync.service
           └─8607 /usr/bin/shairport-sync --daemon

jul 10 00:04:06 raspberrypi systemd[1]: Starting ShairportSync AirTunes receiver...
jul 10 00:04:06 raspberrypi systemd[1]: Started ShairportSync AirTunes receiver.
jul 10 00:04:22 raspberrypi shairport-sync[8607]: Error 6 opening the pipe named "/tmp/snapfifo_shairport": "No such device or address".

then i've altered the .service to have the -vv argument (for more verbose log), and run sudo systemctl status shairport-sync again, the output was:

● shairport-sync.service - ShairportSync AirTunes receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-07-10 12:55:55 -03; 31s ago
     Docs: man:shairport-sync(7)
           file:///usr/share/doc/shairport-sync/README.md.gz
           https://github.com/mikebrady/shairport-sync
  Process: 19297 ExecStart=/usr/bin/shairport-sync --daemon $DAEMON_ARGS -vv (code=exited, status=0/SUCCESS)
 Main PID: 19299 (shairport-sync)
    Tasks: 10 (limit: 4915)
   Memory: 3.0M
   CGroup: /system.slice/shairport-sync.service
           └─19299 /usr/bin/shairport-sync --daemon -vv

jul 10 12:55:55 raspberrypi shairport-sync[19299]: audio backend desired buffer length is 1.000000 seconds.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: audio backend latency offset is 0.000000 seconds.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: audio backend silence lead-in time is -1.000000 seconds. A value -1.0 means use the default.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: volume range in dB (zero means use the range specified by the mixer): 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: zeroconf regtype is "_raop._tcp".
jul 10 12:55:55 raspberrypi shairport-sync[19299]: decoders_supported field is 1.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: use_apple_decoder is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: alsa_use_hardware_mute is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: no special mdns service interface was requested.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: configuration file name "/etc/shairport-sync.conf" resolves to "/etc/shairport-sync.conf".
jul 10 12:55:55 raspberrypi shairport-sync[19299]: metadata enabled is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: metadata pipename is "(null)".
jul 10 12:55:55 raspberrypi shairport-sync[19299]: metadata socket address is "(null)" port 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: metadata socket packet size is "500".
jul 10 12:55:55 raspberrypi shairport-sync[19299]: get-coverart is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: convolution is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: convolution IR file is "(null)"
jul 10 12:55:55 raspberrypi shairport-sync[19299]: convolution max length 8192
jul 10 12:55:55 raspberrypi shairport-sync[19299]: convolution gain is 0.000000
jul 10 12:55:55 raspberrypi shairport-sync[19299]: loudness is 0.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: loudness reference level is -20.000000
jul 10 12:55:55 raspberrypi shairport-sync[19299]: disable resend requests is off.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: diagnostic_drop_packet_fraction is 0.000000. A value of 0.0 means no packets will be dropped deliberately.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: avahi: service 'AF31192A3A11@Raspberrypi' group is not yet committed.
jul 10 12:55:55 raspberrypi shairport-sync[19299]: avahi: request to add "_raop._tcp" service without metadata
jul 10 12:55:55 raspberrypi shairport-sync[19299]: avahi: service 'AF31192A3A11@Raspberrypi' group is registering.
jul 10 12:55:56 raspberrypi shairport-sync[19299]: avahi: service 'AF31192A3A11@Raspberrypi' successfully added.
jul 10 12:56:11 raspberrypi shairport-sync[19299]: New RTSP connection from 192.168.1.106:50347 to self at 192.168.1.11:5000 on conversation thread 1.
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "ANNOUNCE":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Length", content: "658"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Type", content: "application/sdp"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "3"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Connection 1: ANNOUNCE
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Play connection from user agent "AirPlay/387.2" on RTSP conversation thread 1.
jul 10 12:56:23 raspberrypi shairport-sync[19299]: AirPlay version 387 detected.
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "3"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "SETUP":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Transport", content: "RTP/AVP/UDP;unicast;mode=record;timing_port=57632;control_port=56128"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "4"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Connection 1: SETUP -- Active-Remote string seen: "1042046567".
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Connection 1: SETUP -- DACP-ID string seen: "70C633FF6541D6DE".
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Connection 1: SETUP -- Connection from 192.168.1.106 to self at 192.168.1.11.
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "4"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Transport", content: "RTP/AVP/UDP;unicast;interleaved=0-1;mode=record;control_port=6001;timing_port=6002;server_port=6003"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Session", content: "1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "RECORD":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "5"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: Connection 1: RECORD
jul 10 12:56:23 raspberrypi shairport-sync[19299]: pbeg
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "5"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Audio-Latency", content: "11025"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "SET_PARAMETER":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Length", content: "18"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Type", content: "text/parameters"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "6"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "6"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "SET_PARAMETER":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Length", content: "18"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Content-Type", content: "text/parameters"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "7"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "7"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1 received an RTSP Packet of type "FLUSH":
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "RTP-Info", content: "seq=32821;rtptime=505224944"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "8"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "DACP-ID", content: "70C633FF6541D6DE"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Active-Remote", content: "1042046567"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "User-Agent", content: "AirPlay/387.2"
jul 10 12:56:23 raspberrypi shairport-sync[19299]: RTSP thread 1: RTSP Response:
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "CSeq", content: "8"
jul 10 12:56:23 raspberrypi shairport-sync[19299]:   Type: "Server", content: "AirTunes/105.1"
jul 10 12:56:24 raspberrypi shairport-sync[19299]: Resend interval for latency of 88200 frames is 31 frames.
jul 10 12:56:24 raspberrypi shairport-sync[19299]: Hammerton Decoder used on encrypted audio.
jul 10 12:56:24 raspberrypi shairport-sync[19299]: pffr
jul 10 12:56:24 raspberrypi shairport-sync[19299]: Error 6 opening the pipe named "/tmp/snapfifo_shairport": "No such device or address".
jul 10 12:56:24 raspberrypi shairport-sync[19299]: prsm

Extra usefull info:

the only non default parameters in shairport-sync.conf are:
```
general =
{
    output_backend = "pipe";
};
```

// bunch of commented code/configs here

pipe = { name = "/tmp/snapfifo_shairport"; };

mikebrady commented 4 years ago

Many thanks for the update. I'm afraid I'm at a loss to explain this, except that I'm using the most recent version -- 3.3.7rc1. Let me suggest that you update to the latest version. Some work has been done on the pipe backend which may have affected (fixed?) this, as it doesn't appear as a problem here.

jgabriel98 commented 4 years ago

So, kinda related but not so much.

I was trying to compile the 3.3.7rc1 version with the configure command: ./configure --sysconfdir=/etc --with-pipe --with-systemd --with-mpris-interface --with-avahi

but when i run make i get some linking errors:

g++ -fno-common -Wno-multichar -Wall -Wextra -Wno-clobbered -Wno-psabi -pthread -DSYSCONFDIR=\"/etc\"  -g -O2   -o shairport-sync shairport.o rtsp.o mdns.o common.o rtp.o player.o alac.o audio.o loudness.o activity_monitor.o  mdns_avahi.o       audio_pipe.o       metadata_hub.o  dacp.o tinyhttp/chunk.o tinyhttp/header.o tinyhttp/http.o  mpris-service.o  lib_mpris_interface.a -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lavahi-common -lavahi-client -lconfig -lpopt -lm -lpthread -lrt 
/usr/bin/ld: rtsp.o: on function "apple_challenge":
/home/pi/Git/shairport-sync/rtsp.c:2242: not defined reference to "base64_dec"
/usr/bin/ld: /home/pi/Git/shairport-sync/rtsp.c:2279: not defined reference to "rsa_apply"
/usr/bin/ld: /home/pi/Git/shairport-sync/rtsp.c:2280: not defined reference to "base64_enc"
/usr/bin/ld: rtsp.o: on function  "make_nonce":
/home/pi/Git/shairport-sync/rtsp.c:2302: not defined reference to "base64_enc"
/usr/bin/ld: rtsp.o: on function  "handle_announce":
/home/pi/Git/shairport-sync/rtsp.c:2098: not defined reference to "base64_dec"
/usr/bin/ld: /home/pi/Git/shairport-sync/rtsp.c:2107: not defined reference to "base64_dec"
/usr/bin/ld: /home/pi/Git/shairport-sync/rtsp.c:2108: not defined reference to "rsa_apply"
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:740: shairport-sync] Error 1
make[2]: Leaving directory '/home/pi/Git/shairport-sync'
make[1]: *** [Makefile:873: all-recursive] Error 1
make[1]: Leaving directory '/home/pi/Git/shairport-sync'
make: *** [Makefile:597: all] Error 2

maybe there are some missing compiler flags, to tell the linker the libraries to link?

note: my language is portuguese(brazilian), so i had to translate the make error log, maybe it is not exactly as the english error log, but the meaning matches.

update

adding the --with-ssl=openssl to ./configured fixed, don't know why

mikebrady commented 4 years ago

Yes, that was what was missing. Perhaps the instructions on the INSTALL.md page might be easier to understand.

jgabriel98 commented 4 years ago

Updating to version 3.3.7rc1 fixed the issue

mikebrady commented 4 years ago

Thank you for the information.

jgabriel98 commented 4 years ago

Update:

the release candidate version 3.3.7rc1 did fixed this specific issue, but i'm afraid it created a new one:

i am currently running the current setup/configuration:

snapserver (from snapcast) creates, open and listen to /tmp/snapfifo pipe
raspotify (a daemon wrapping librespot) open and write to /tmp/snapfifo (it doesn't create it)
shairport-sync creates, open and write to /tmp/snapfifo

both raspotify and shairport-sync are configured to use pipe as the backend, and snapserver to use the same pipe as input stream.

When i manually start snapserver first, then raspotify and shairport-sync, everything works. But if shairport-sync starts before snapserver, i get the following error on raspotify (librespot):

jul 26 12:50:23 raspberrypi systemd[1]: Starting Raspotify...
jul 26 12:50:23 raspberrypi systemd[1]: Started Raspotify.
jul 26 12:50:23 raspberrypi librespot[3326]: [2020-07-26T15:50:23Z INFO  librespot] librespot (raspotify v0.14.0) 3672214 (2020-01-30). Built on 2020-02-16. Build ID: 7pZDdYUK
jul 26 12:50:32 raspberrypi librespot[3326]: [2020-07-26T15:50:32Z INFO  librespot_core::session] Connecting to AP "guc3-accesspoint-b-cpd5.ap.spotify.com:4070"
jul 26 12:50:33 raspberrypi librespot[3326]: [2020-07-26T15:50:33Z INFO  librespot_core::session] Authenticated as "jgabriel98" !
jul 26 12:50:33 raspberrypi librespot[3326]: thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/libcore/result.rs:1188:5

so, i think that the shairport-sync opens the pipe in a non-friendly way.

maybe creating a service that justs creates this pipe before everyone, and make everyone start after this service start, would be a valid workarround. But it does not to be a very clean way neither stable/flexible one.

personal note: anyway, still thanks for this amazing software!

mikebrady commented 4 years ago

Thanks for the post, and thanks for the troubleshooting. Would it be possible for you to check the ownership and permissions of the pipe both when it is used successfully and when it is unsuccessful, please?

jgabriel98 commented 4 years ago

when used successfully (snapserver creates the fifo first): ls -l /tmp/snapfifo outputs: prw-rw-rw- 1 snapserver snapserver 0 jul 26 13:58 /tmp/snapfifo so, it means: owner: snapserver group: snapserver read: any one write: any one execute: no one

when used unsuccessful (shairport-sync creates the fifo first): ls -l /tmp/snapfifo outputs: prw-r--r-- 1 shairport-sync shairport-sync 0 jul 26 14:10 /tmp/snapfifo so, it means: owner: shairport-sync group: shairport-sync read: any one write: only owner execute: no one

mikebrady commented 4 years ago

Thanks. I think your analysis is right -- the sequence is Owner/Group/World reading the rightmost 9 flags.

I will (tomorrow!) change it to match the permissions that snapserver gives it. Hopefully that will fix the problem...

mikebrady commented 4 years ago

Okay, so I've pushed an update to the development branch, version 3.3.7d15, which creates the metadata pipe (and the audio pipe when using the pipe backend) with permissions rw-rw-rw-. I'd be grateful for your feedback when you get a chance.

(BTW, it's hard to understand why snapserver seems to need write permission to the pipe. I don't get that.)

jgabriel98 commented 4 years ago

Happy to know, thanks!

But i think you got one thing wrong: actually snapserver dont need write permission to the pipe. i just need read permission, just like told here:

i am currently running the current setup/configuration:

snapserver (from snapcast) creates, open and listen to /tmp/snapfifo pipe

raspotify (a daemon wrapping librespot) open and write to /tmp/snapfifo (it doesn't create it)

shairport-sync creates, open and write to /tmp/snapfifo

So the problem is that raspotify and shairport-sync tries to write to the same pipe. So when snapserver creates it, everything went okay, because it had "wide" write permission. But when shairport-sync creates it, things go wrong, since only shairport-sync could write to it.

Now about the choice to change the fifo pipe permissions when shairport-sync creates it:

giving rw-rw-rw- permissions to the audio pipe would solve the problem, but it seems to be solving my problem specific? Actually i would prefer this, because it is just convenient for my issue. But i choose to talk about this just to let you think about it, and conclude if it really is the correct solution (given the easiness to implement it).
giving rw-rw-rw- permissions to the metadata pipe doesn't make much sense, since it doesn't seem to be required, and i dont't see any case where another process would want to write to the same metadata pipe. (for the audio pipe kinda makes sense, because both process would be sending audio in the same way, but for metada it doesn't, because i have a specific format/structure)

personal note: sorry if you found my explanation too confusing, english is not my mother language, so sometimes is hard to explain specific details.

mikebrady commented 4 years ago

Many thanks for your explanation. Your English is fine (much better than my (?) Portuguese). I simply misunderstood the problem, even though you had described it clearly.

I agree your logic about giving rw-rw-rw- access to the audio pipe and not the metadata pipe and I will make that change. Thinking broadly about integrating Shairport Sync with other PCM sources, it makes sense that it should be created to be writable by others.

It may be a little while before I make the change -- a few days, perhaps.

jlssmt commented 3 years ago

Any updates? I'm also in trouble with snapfifo file and shairport-sync. Everytime shairport-sync starts, it annex the file to his own and no other application can write it anymore.

mikebrady commented 3 years ago

Thanks for the post. I thought that this has been fixed. Can you post the version string of Shairport Sync please?

jlssmt commented 3 years ago

ahhh i see. i use a older version than github release. but it's the latest apt release on my raspbian buster: Version: "3.2.2-OpenSSL-Avahi-ALSA-pa-dummy-stdout-pipe-soxr-convolution-metadata-sysconfdir:/etc"

mikebrady commented 3 years ago

Thanks — mystery solved! It’s not too difficult to build Shairport Sync yourself. Just make sure you remove everything associated with the existing version beforehand.

mikebrady / shairport-sync

Error 6 on opening pipe: "No such device or address". #1037

update