Shairport-Sync disappears from being an Airplay device.

[silentq]

I have noticed that Shairport-Sync on my Raspbian install seems to have an issue where at first its boots up fine, accepts playback from both my iPhone and iTunes just fine. After about about 5 minutes during playback(at times it did this once and never again) or if left without a connection to a source, the raspberry pi is no longer available as an Airplay device on the iPhone or iTunes. It appears in Raspbian that there is a Daemon for Shairport-Sync running but it will just refuse to offer or accept any connections. Been looking around online I can't seem to find others with this issue. I have the newest version of Shairport-Sync since I just installed it today. Any help would be appreciated.

[silentq]

So just an update on this issue, I booted up my pi again and shairport-sync worked fine was able to connect and play from itunes and ios but once I disconnected the pi was available to connect to for a few minutes and then it disappeared again. I walked away from it for about an hour and it was then available again. I was able to connect again disconnect and it was still available just fine. I rebooted once more to see if I could replicate this behavior, but the next time I was able to connect/disconnect and it disappeared once again but this time it never came back even after leaving the device on overnight. At this point not sure if this is an issue or a setting that isn't there. In each instance I ran top to make sure the shairport-sync was running and it is and it never stops.

[mikebrady]

Thanks for the information. Can you tell me what version of Shairport Sync you're running please? If you enter shairport-sync -V the reply will give the version information.

[silentq]

Hi Mike, This is my version: pi@raspberrypi:~ $ shairport-sync -V 2.6-openssl-Avahi-ALSA

Thanks!

[mikebrady]

Thanks. That seems fine and dandy.

A thing that sometimes happens is that the WiFi adapter in the Raspberry Pi has a low-power mode and kind-of drops off the network after a period. Usually you can prevent it from going into the low-power mode, but the method varies from device to device. Google is your friend here.

[silentq]

Well this particular device is not on wifi it is actually on ethernet. I have seen some people run into issues with the wifi power setting and when I get a wifi dongle I will deal with that. Be that as it may I am not sure why this behavior would exist over ethernet?

[mikebrady]

Thanks. It would be interesting to know if the Pi is accessible when the AirPlay service disappears. Can it be pinged and ssh'ed when the service is gone. Are the sending devices on WiFi or a mixture?

[silentq]

So yeah thats the weird part of it all I am able to ssh into the pi once the device goes missing. The two devices that I am trying to airplay to the pi are a Macbook and an iPhone which are both on wifi.

[silentq]

Hi Mike,

Update I had stepped away since the last time I rebooted. I come back about 2 hours later(2:23 to be exact I checked the uptime) and its back up after initially losing the device for a while. I was wondering if there's any specific logs I can relay back to you maybe to help with some insight on this as this is quite weird behavior.

Note: once the pi is visible again to the other devices it seems to never disapear again and is connectable by all devices, that is until you reboot initially connect and it drops off again. This is what I noted earlier in my second post.

[mikebrady]

Thanks for the update. It is indeed puzzling. I know some other users have had problems caused by the router, often most pronounced when crossing from one mode to the other, e.g. from WiFi to Ethernet, as if multicast isn't correctly handled. I don't really know how you would test for it though.

There is an app for the Mac called Bonjour Browser and an equivalent for iOS called Discovery. They both have the same icon. They allow you to see what's is being advertised by Bonjour. Perhaps they might help you explore what is and isn't visible at each machine's ports.

[silentq]

Really Bizarre, so I got discovery like you had suggested I found the under the Remote Audio Output Protocol(_raop_tcp.) I see the following for the pi:

raspberrypi.local:5000

ch=2 cn = 0,1 ek = 1 et =0,1 pw = false sm = false sr = 44100 ss= 16 tp= UDP txtvers = 1 vn = 3

Weirdest thing though is after I rebooted it is not doing this anymore. I will do further testing but I have no clue why since I installed discovery on iOS it just stopped doing this. I guess that is a good thing but I was kinda hoping a root cause to the issue would pop up but I guess chalk up to the weirdness of Airplay. I am not sure haha.

[mikebrady]

Weird is right :) It (the Raspberry Pi's advertisement of RAOP) should be visible at both ends – the Pi and the sender... You can install avahi-utils on the Pi. There's a program in it called avahi-browse, and it can show you what the Pi thinks it's putting out. Here's an extract:

$ avahi-browse -ar
+   eth0 IPv6 B2D2AB9E0xxx@IQaudIO                          AirTunes Remote Audio local
+   eth0 IPv4 B2D2AB9E0xxx@IQaudIO                          AirTunes Remote Audio local
+   eth0 IPv6 raspberrypi [b8:27:xx:xx:xx:xx]               Workstation          local
+   eth0 IPv4 raspberrypi [b8:27:xx:xx:xx:xx]               Workstation          local

[snip]

=   eth0 IPv4 B2D2AB9E0xxx@IQaudIO                          AirTunes Remote Audio local
   hostname = [raspberrypi.local]
   address = [192.168.2.2]
   port = [5000]
   txt = ["pw=true" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"]

[snip]

=   eth0 IPv6 B2D2AB9E0xxx@IQaudIO                          AirTunes Remote Audio local
   hostname = [raspberrypi.local]
   address = [fe80::xxxx:xxxx:xxxx:xxxx]
   port = [5000]
   txt = ["pw=true" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"]

[silentq]

Hey Mike,

So just to follow up, the issue later popped up after a couple of hours. I got my wifi card in the mail today and hooked it all up and it works perfectly now. I think what you said about going between wifi devices and ethernet devices causes an issue. That's the only conclusion I can come to since I have gone longer than ever with the pi being visible after connecting/disconnecting that I have ever seen. Again I know no root cause has been truly discovered here but I guess I would recommend caution when going between wifi and ethernet.

[mikebrady]

That's good news. There is no particular reason there should be a problem going between the different mediums. I guess it's down to the software running the router, but if could be really hard to detect and fix. Thanks for the update.

[mikebrady]

I think this issue is resolved, so I'm going to close it. Feel free to reopen it if not.