search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD media server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2k stars 231 forks source link

AirPlay Outputs disappear #496

Open chesterdkat opened 6 years ago

chesterdkat commented 6 years ago

Once or twice a day I find that all outputs except for the Computer itself disappear from both the forked-daapd web interface as well as Apple's Remote app on my iPhone and iPad. I presently have 2 Airport Expresses and 2 Apple TV 4's paired. I have to go to the terminal and issue a restart of forked-daapd to have them reappear. iTunes does not have any issue with the availability of these same AirPlay devices.

I'm running forked-daapd version 25.0 on a Raspberry Pi 3b. Thanks...

ejurgensen commented 6 years ago

Can you investigate what the log says? I think even with the log level set to the default "log", you should see some message in the log when the outputs get removed. If you don't, then set the log level to "debug" (but please don't post the entire log here... just the part that concerns forked-daapd removing the output).

chesterdkat commented 6 years ago

Sure! See following after losing the “Living Room Express”:

[2018-02-23 11:28:08] [ LOG] lib: Library init scan completed in 1501 sec (0 changes) [2018-02-23 12:08:19] [ LOG] cache: Beginning DAAP cache update [2018-02-23 12:08:53] [ LOG] cache: DAAP cache updated [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:58:40] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:14:39] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:21:07] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:06:26] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:06:26] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached

On Feb 23, 2018, at 11:11 AM, ejurgensen notifications@github.com wrote:

Can you investigate what the log says? I think even with the log level set to the default "log", you should see some message in the log when the outputs get removed. If you don't, then set the log level to "debug" (but please don't post the entire log here... just the part that concerns forked-daapd removing the output).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ejurgensen/forked-daapd/issues/496#issuecomment-368055128, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYGko9R7mPCM9SV54ArVAFphC5WjaKPks5tXuM5gaJpZM4SRB2y.

chesterdkat commented 6 years ago

Here is an update where the rest of my AirPlay devices disappeared:

[2018-02-23 11:28:08] [ LOG] lib: Library init scan completed in 1501 sec (0 changes) [2018-02-23 12:08:19] [ LOG] cache: Beginning DAAP cache update [2018-02-23 12:08:53] [ LOG] cache: DAAP cache updated [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 12:35:22] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:34:08] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 13:58:40] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:04:10] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:14:39] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 14:21:07] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:06:26] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:06:26] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:33:42] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:33:42] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:47:34] [ LOG] mdns: Avahi Resolver failure: service '00254B071E5A@Audrey's Bedroom' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:47:34] [ LOG] mdns: Avahi Resolver failure: service '001FF3F4E6DC@Living Room Express' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:47:34] [ LOG] mdns: Avahi Resolver failure: service 'C869CD07FFC4@Family Room' type '_raop._tcp' proto 0: Timeout reached [2018-02-23 15:47:34] [ LOG] mdns: Avahi Resolver failure: service 'D0034BF10027@Master Bedroom' type '_raop._tcp' proto 0: Timeout reached

On Feb 23, 2018, at 11:11 AM, ejurgensen notifications@github.com wrote:

Can you investigate what the log says? I think even with the log level set to the default "log", you should see some message in the log when the outputs get removed. If you don't, then set the log level to "debug" (but please don't post the entire log here... just the part that concerns forked-daapd removing the output).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ejurgensen/forked-daapd/issues/496#issuecomment-368055128, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYGko9R7mPCM9SV54ArVAFphC5WjaKPks5tXuM5gaJpZM4SRB2y.

ejurgensen commented 6 years ago

This normally means that the service disappears, e.g. if it gets switched off. In this case it could be your wifi somehow being interrupted? So my suggestion would be to test with another router.

ejurgensen commented 6 years ago

However, I'm not sure I understand why the devices do not re-appear. Maybe there is a problem in forked-daapd there. Not sure how to reproduce that, though.

chesterdkat commented 6 years ago

All my devices are connected via Ethernet (no WiFi). My router is pfSense on a SuperMicro server motherboard so way overkill for my needs and solid as a rock. All (except for the Pi NIC) is Gigabit. No issues with my Mac mini and iTunes so it has to be Pi running forked-daapd.

On Feb 24, 2018, at 9:49 AM, ejurgensen notifications@github.com wrote:

However, I'm not sure I understand why the devices do not re-appear. Maybe there is a problem in forked-daapd there. Not sure how to reproduce that, though.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ejurgensen/forked-daapd/issues/496#issuecomment-368233321, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYGktF7HjB8bXfQE2g2d-Z2_GIcOryWks5tYCFngaJpZM4SRB2y.

ejurgensen commented 6 years ago

Yes, then the issue must be somewhere else. I don't think I will be able to find out why Avahi is giving those resolver callbacks in your case. My own setup is also always on, and I don't see this.

Instead I will try to produce the error by cutting a network connection and then re-establishing it. If the speaker does not come back, then there might be something I can do.

chesterdkat commented 6 years ago

Thank you!

On Feb 25, 2018, at 03:59, ejurgensen notifications@github.com wrote:

Yes, then the issue must be somewhere else. I don't think I will be able to find out why Avahi is giving those resolver callbacks in your case. My own setup is also always on, and I don't see this.

Instead I will try to produce the error by cutting a network connection and then re-establishing it. If the speaker does not come back, then there might be something I can do.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ejurgensen commented 6 years ago

Now I changed my ATV to Ethernet, and I tried the following:

In both instances I get the timeout message, but the ATV also got added again, as it should. So I am not able to reproduce what you are seeing.

Two suggestions:

slimey commented 6 years ago

I am in exactly the same situation (version 25.0 on Raspberry Pi 3, server and ATVs connected via wired Ethernet on a rock-solid over-specified network, ATVs usable via other means, server showing no other issues, and seeing the ATV outputs disappear intermittently from forked-daapd).

With debug turned on and restarting, the ATV endpoints are correctly discovered, then timed out three seconds later. mdns debug here - let me know if other parts of the debug (or anything else) would be useful.

Thanks!

jshep321 commented 6 years ago

Hi, I see a very similar problem intermittently, but it seems to be much more frequent with my apple devices (airport express) than with my pi zero W's. I have switched routers from airport extreme to netgear orbi and can see that the device is IP-connected via the router as well as recognized from airport utility on iphone/mac.

I have 9 endpoints, including 2 ATVs and 1 firestick.

I am wondering if there are some overloading issues on avahi? It seems that itunes (or the mac it is running on) is doing something to keep these devices alive/connected that the pi avahi is not. If I restart the forked-daapd server or the missing endpoint, it usually fixes the problem.

Will investigate further... when I get time.

ejurgensen commented 6 years ago

If restarting forked-daapd helps then it makes me think that the problem is between avahi and forked-daapd. After restart forked-daapd gets a list of announcements from avahi, so that must mean avahi has registered all device announcements, but that some of those have not been sent on to forked-daapd. That could be a bug in forked-daapd, maybe under special conditions the service browsers don't register what avahi is notifying them about.

Since I can't reproduce it would be great if you would investigate. Maybe run avahi-browse + forked-daapd with at least info log level. Then see if you can catch a device reappearing in avahi-browse that is not properly picked up by forked-daapd.

jshep321 commented 6 years ago

Ok so my "Master Bathroom" airport express disappeared this morning from my outputs (not shown via mpc outputs or the iphone remote app) and reappeared when I did a "systemctl restart" of forked-daapd. Are there any "secret" items in the avahi-browse or forked-daapd logfiles before I post them? I see some hex strings that look like they might be secret?

ejurgensen commented 6 years ago

No, there shouldn't be anything secret, but you can remove the hex strings if you want. I'm mainly interested in seeing what events are registered by avahi and forked-daapd.

jshep321 commented 6 years ago

Hi @ejurgensen , OK thanks.... logs here:

ejurgensen commented 6 years ago

Your issue seems different than op's. The log shows that at 10:32 Avahi told forked-daapd to remove the service: [2018-06-19 10:32:00] [DEBUG] mdns: Avahi Browser: REMOVE service 'D830622E6724@Master Bathroom' type '_raop._tcp' proto 0 Sadly, there isn't really any clue why that happened. Avahi also gives no further notifications about the device.

I have an ATV4 to test with now, and I have found some problems with ipv6 that I have tried to fix in this branch: https://github.com/ejurgensen/forked-daapd/tree/mdns_revisited

You are welcome to test, but I am not sure the issues I am fixing are related to yours.

ejurgensen commented 6 years ago

The mdns changes I made to fix the problems I saw with my own ATV4 are now in the master branch. Can't say if they fix any of the above issues.

ejurgensen commented 6 years ago

I've had my new ATV4 running for a couple of days now, and with latest fixes it seems to be stable. I have not seen the device disappear or being unconnectable. It would be great if you could test it as well. If you use my RPi version it is available in my repo as build 26.2.70.

fmalfatto commented 5 years ago

I still have this problem on raspbian stretch with 26.3.73.gitaa3aa38-2. The outputs listed from the web interface are changing during day, but they are complete only after a restart. When one is unused for a while, it disappear, also if is still listed by avahi-browse:

$ avahi-browse -kt _raop._tcp

At the same time fordked-daapd reports: Outputs: Bose Ospiti SONY

I do not have IPV6 and the Airplay devices work normally out of forked-daapd.

ejurgensen commented 5 years ago

What does the log say? Set the log level to ‘info’ or lower.

fmalfatto commented 5 years ago

[2018-11-02 13:44:49] [ INFO] raop: Adding AirPlay device 'Bose': password: 0, verification: 0, encrypt: 0, authsetup: 1, metadata: 0, type Other, address 192.168.1.141:1024 [2018-11-02 13:44:50] [ INFO] raop: Adding AirPlay device 'SONY': password: 0, verification: 0, encrypt: 0, authsetup: 1, metadata: 0, type Other, address 192.168.1.142:1041 [2018-11-02 14:09:35] [ INFO] raop: Adding AirPlay device 'AppleTV': password: 0, verification: 1, encrypt: 0, authsetup: 0, metadata: 1, type AppleTV4, address 192.168.1.175:7000 [2018-11-02 14:09:35] [ INFO] raop: Adding AirPlay device 'Lavanderia': password: 0, verification: 0, encrypt: 1, authsetup: 0, metadata: 0, type Other, address 192.168.1.11:5000 [2018-11-02 14:27:55] [ LOG] mdns: Avahi Resolver failure: service 'EF13831FCBBB@Lavanderia' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 14:27:55] [ INFO] player: Removing AirPlay device 'Lavanderia'; stopped advertising [2018-11-02 14:27:55] [ LOG] mdns: Avahi Resolver failure: service '5453ED14C3D8@SONY' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 14:27:55] [ INFO] player: Removing AirPlay device 'SONY'; stopped advertising [2018-11-02 14:27:55] [ LOG] mdns: Avahi Resolver failure: service '000C8A575193@Bose' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 14:27:55] [ INFO] player: Removing AirPlay device 'Bose'; stopped advertising [2018-11-02 14:27:55] [ LOG] mdns: Avahi Resolver failure: service 'D0034B1A8C67@AppleTV' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 14:27:55] [ INFO] player: Removing AirPlay device 'AppleTV'; stopped advertising

ejurgensen commented 5 years ago

Ok. I’m afraid I can’t think of any solution, as you can see Avahi is saying the device is no longer there. If I could at least reproduce I could get a better understanding of what Avahi is doing - and why it is not at least notifying about device reappearance.

fmalfatto commented 5 years ago

But it seems that raop notifies when a device reappears, but forked-daapd does not catch it:

[2018-11-02 21:34:09] [ LOG] mdns: Avahi Resolver failure: service '000C8A575193@Bose' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 21:34:09] [ INFO] player: Removing AirPlay device 'Bose'; stopped advertising [2018-11-02 21:34:09] [ LOG] mdns: Avahi Resolver failure: service '5453ED14C3D8@SONY' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 21:34:09] [ INFO] player: Removing AirPlay device 'SONY'; stopped advertising [2018-11-02 21:34:09] [ LOG] mdns: Avahi Resolver failure: service 'D0034B1A8C67@AppleTV' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 21:34:09] [ INFO] player: Removing AirPlay device 'AppleTV'; stopped advertising [2018-11-02 21:34:11] [ LOG] mdns: Avahi Resolver failure: service 'EF13831FCBBB@Lavanderia' type '_raop._tcp' proto 0: Timeout reached [2018-11-02 21:34:11] [ INFO] player: Removing AirPlay device 'Lavanderia'; stopped advertising [2018-11-02 21:38:07] [ LOG] spotify: No spotify refresh token found [2018-11-02 21:38:14] [ INFO] raop: Adding AirPlay device 'Bose': password: 0, verification: 0, encrypt: 0, authsetup: 1, metadata: 0, type Other, address 192.168.1.141:1024 [2018-11-02 21:38:14] [ INFO] raop: Adding AirPlay device 'SONY': password: 0, verification: 0, encrypt: 0, authsetup: 1, metadata: 0, type Other, address 192.168.1.142:1041 [2018-11-02 21:38:14] [ INFO] raop: Adding AirPlay device 'AppleTV': password: 0, verification: 1, encrypt: 0, authsetup: 0, metadata: 1, type AppleTV4, address 192.168.1.175:7000 [2018-11-02 21:38:16] [ INFO] raop: Adding AirPlay device 'Lavanderia': password: 0, verification: 0, encrypt: 1, authsetup: 0, metadata: 0, type Other, address 192.168.1.11:5000

ejurgensen commented 5 years ago

"raop" is part of forked-daapd, so when it says "Adding AirPlay device..." the device is certainly being added to forked-daapd's list. Can you can check the list with "mpc outputs"? Just to avoid client issues.

fmalfatto commented 5 years ago

At the moment of the log, forked-daapd shows only two outputs. After restarting avahi it shows them all.

mpc outputs

Output 23091 (Ospiti) is enabled

avahi-browse -kt _raop._tcp

systemctl restart avahi-daemon

mpc outputs

Output 35944 (AppleTV) is disabled Output 20884 (Bose) is disabled Output 52156 (Lavanderia) is disabled Output 23091 (Ospiti) is enabled Output 50137 (SONY) is disabled

"Ospiti" is the only Airplay device directly managed on the same forked-daap server PI2 by shairport-sync. "Lavanderia" is on another Rapberry with shairport-sync too. The other 3 devices are standalone Airplay. All the devices are on the same network 192.168.1.0/24, ATV and the 2 Raspberrys are ethernet wired with static addresses, The Bose/Sony speakers are on WiFI with static addresses fixed by DHCPD. I have an Ipad2 and all the devices are perfectly seen and addressed from native Airplay support on Ipad and also from some app supporting Airplay on my android smartphone (DoubleTwist player. MALP and MPdroid). It looks as only the Raspbian mDSN is not working well

fmalfatto commented 5 years ago

RESOLVED! I do not know what exactly was happening, but I had some arp and/or mcast problems due to the configuration of dns/avahi server. It had two ip addresses on the same interface, needed to distinguish services with different dns names. This leads to unstable mdns behavior. TY to all !!

aprosvetova commented 5 years ago

The problem is still there. I have a Raspberry Pi running forked-daapd and 3 outputs:

  1. HomePod via AirPlay
  2. Apple TV 4 via AirPlay
  3. internal Pi DAC

Both DAC and Apple TV work correctly but HomePod always disappear from the list with this error: [2018-11-15 21:13:36] [ LOG] mdns: Avahi Resolver failure: service '------------@Bedroom' type '_raop._tcp' proto 0: Timeout reached

It actually disappears from all custom AirPlay clients like AirFoil, etc, but it's always available on iOS and macOS!

Furthermore, when I open iOS control center (even without streaming, just to check out) it shows "connecting..." on my HomePod for a sec and then metadata appears. And yeah, HomePod becomes visible for all clients including forked-daapd! But if I don't stream anything for ~10 mins it disappears again and I need to "reactivate" it like this to make it available to forked-daapd. Sometimes HomePod appears by itself without any forcing like described, maybe my iOS/macOS devices do this in background?

This gets me to the point that HomePod goes in kind of a standby mode and native (iOS/macOS) clients have a magic ability to wake it up. With this thoughts I decided to go deeper and used Wireshark to look into the traffic between my macOS laptop and the HomePod. I didn't find any special requests, just well-known /pair-verify, /pair-setup, etc.

So now I have a different idea: maybe HomePod stops announcing itself over mdns while still being available to receive streams and answer requests?

Let's have something like a "retain" or "cache" option for "airplay" config block. When set to true, it should keep the device listed even if Avahi suddenly fails with timeout. Such option will be very useful for my case and I'm sure there are lots of people experiencing same problems (I actually checked and found lots of reports).

I'm still not sure this is a correct reason and solution, but I have no other ideas. I can't submit PR by myself cause I'm too bad at C and didn't even manage to compile the project, so I use package from apt.

ejurgensen commented 5 years ago

Yes, such an option would be possible - setting it would just make forked-daapd not remove devices on mdns timeout, so quite easy to do. However, it is so so dirty that I'm not sure I can make myself do it. One idea: Perhaps iOS/macOS are actually using _airplay._tcp, and not _raop._tcp? If you have leave avahi-browse running with _airplay._tcp perhaps you can see if these announcements behave differently?

aprosvetova commented 5 years ago

@ejurgensen, ok, will try.

About the dirty hack: you can unlist speaker when user tries to play audio through it and it appears offline. Looks not so dirty, just lazy state update

aprosvetova commented 5 years ago

_raop._tcp:

root@raspberrypi:~# avahi-browse _raop._tcp -v -r
Server version: avahi 0.6.32; Host name: raspberrypi-2.local
E Ifce Prot Name                                          Type                 Domain
+   eth0 IPv4 ------------@Bedroom                          AirTunes Remote Audio local
+   eth0 IPv4 ------------@Office                           AirTunes Remote Audio local
+   eth0 IPv4 ------------@Living Room                      AirTunes Remote Audio local

=   eth0 IPv4 ------------@Office                           AirTunes Remote Audio local
   hostname = [raspberrypi-2.local]
   address = [192.168.1.10]
   port = [5000]
   txt = ["pw=false" "txtvers=1" "ch=2" "cn=0,1" "ek=1" "et=0,1" "sv=false" "da=true" "sr=44100" "ss=16" "vn=65537" "tp=TCP,UDP" "vs=105.1" "am=ShairportSync" "fv=76400.10" "sf=0x4"]

=   eth0 IPv4 ------------@Living Room                      AirTunes Remote Audio local
   hostname = [Living-Room.local]
   address = [192.168.1.11]
   port = [7000]
   txt = ["vv=2" "ov=12.1.1" "vs=375.3" "vn=65537" "tp=UDP" "pk=------------" "am=AppleTV5,3" "md=0,1,2" "sf=0x10644" "ft=0x5A7FFFF7,0x155FDE" "et=0,3,5" "da=true" "cn=0,1,2,3"]

Failed to resolve service '------------@Bedroom' of type '_raop._tcp' in domain 'local': Timeout reached

_airplay._tcp:

root@raspberrypi:~# avahi-browse _airplay._tcp -v -r
Server version: avahi 0.6.32; Host name: raspberrypi-2.local
E Ifce Prot Name                                          Type                 Domain
+   eth0 IPv4 Bedroom                                       _airplay._tcp        local
+   eth0 IPv4 Living Room                                   _airplay._tcp        local

=   eth0 IPv4 Living Room                                   _airplay._tcp        local
   hostname = [Living-Room.local]
   address = [192.168.1.11]
   port = [7000]
   txt = ["vv=2" "osvers=12.1.1" "srcvers=375.3" "pk=------------" "psi=------------" "pi=------------" "protovers=1.1" "model=AppleTV5,3" "gcgl=1" "igl=1" "gid=------------" "flags=0x10644" "features=0x5A7FFFF7,0x155FDE" "deviceid=------------" "acl=0"]

=   eth0 IPv4 Bedroom                                       _airplay._tcp        local
   hostname = [Bedroom.local]
   address = [192.168.1.12]
   port = [7000]
   txt = ["vv=2" "osvers=12.1" "srcvers=373.9.1" "pk=------------" "psi=------------" "pi=------------" "protovers=1.1" "model=AudioAccessory1,1" "gcgl=1" "igl=1" "gid=------------" "flags=0x18404" "features=0x4A7FCA00,0x156BD0" "deviceid=------------" "acl=0"]

I've added some line-breaks to make it easier to read. I have 3 AirPlay speakers on my network: Bedroom (HomePod), Living Room (Apple TV 4), Office (shairport-sync). As you can see, they all broadcast on _raop._tcp but avahi fails to resolve my HomePod info. When I listen to _airplay._tcp it successfully finds and resolves my HomePod info and Apple TV 4 too but it doesn't find my shairport-sync instance maybe because it doesn't support new protocol.

So do we need to combine both ways to get all devices' status up to date or what?..

aprosvetova commented 5 years ago

Now I think it looks like HomePod always answers with device info on _airplay._tcp but stops timeouting on _raop._tcp only when gets 'triggered' and in purpose of backward compatibility.

ejurgensen commented 5 years ago

The config option + the handling of _airplay._tcp is now in the master branch. @aprosvetova it would be great if you would test, preferably without using the config option. I hope the _airplay._tcp handling in itself solves the issue, so users don't need to set any special config.

aprosvetova commented 5 years ago

@ejurgensen yay! Would be happy to test! I remember I had annoying problems with compiling forked-daapd on my RPi, so is there any chance of getting a Raspbian package?

ejurgensen commented 5 years ago

Sure, here is deb for Stretch: http://gyfgafguf.dk/temp/forked-daapd_26.3.75~rc4-2_armhf.deb

aprosvetova commented 5 years ago

Hmm... @ejurgensen I've installed this package and restarted my forked-daapd, but it looks like it didn't update. Btw I have 26.4 version but your package is named 26.3.75...

aprosvetova commented 5 years ago

Oh, sorry, looks like it was updated successfully. And wtf:

1llmes13vb

You remember I checked this manually with avahi browser and it was working with _airplay._tcp!

ejurgensen commented 5 years ago

Yeah that's not great. The change will of course not make work if _airplay._tcp also times out.

Not sure what to do from here. Maybe I should try and get hold of a Homepod. I might revert the change in the meantime. I will leave the config option.

Yes, it is 26.3 is a mistake, it should have been named 26.4.

aprosvetova commented 5 years ago

I might revert the change in the meantime.

Hey, let's keep it for a while. Maybe I'm wrong somewhere else and this should have helped.

brianegge commented 2 years ago

Finally got to the bottom of this (for me). I have a managed switch at home but not an IGMP queries. If you have dumb switches they forward multicast to all ports. If your have a managed switch, it can snoop for IGMP packets to know which devices want each subscription. But you must have an IGMP querier running somewhere on the network. High end switches have one but most home stuff does not. You either need an IGMP querier or disable IGMP snooping.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736641

I tried to run a software IGMP queries but without success: https://github.com/machinekoder/querierd netgear

pisabird commented 1 week ago

Hello

I still have the same problem with version Version 28.6

[2024-06-26 13:00:53] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached [2024-06-26 13:01:37] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached [2024-06-26 13:39:49] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached [2024-06-26 13:44:57] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached

Any news on this?

ejurgensen commented 1 week ago

Well, I made a fix recently for an issue where OwnTone wouldn't detect when a speaker changed ip address, so there is a chance that this fix also helps with this issue. However, since I was never able to reproduce the above I can't really say.

pisabird commented 1 week ago

How can I get this fixed? It is very important for me to stay on Version 28.6, because with all later versions I have another issue.

ejurgensen commented 1 week ago

What issue is that?

pisabird commented 1 week ago

I don't have the choice button for speaker (navbar-item fd-margin-left-auto is-hidden-desktop) on my mobile phone. The field left is too large so that this filed can't show on a mobile....

I marked it also red in the picture. photo_5467804890832166555_y

ejurgensen commented 1 week ago

Ok maybe @hacketiwack can do something about that

hacketiwack commented 1 week ago

@pisabird what device are you using (I'm interested in the version of the web browser)? And which version of OwnTone are you using?

pisabird commented 1 week ago

Hello hacketiwack

I am using iPhone mini 13 - Safari with IOS 16.6 - OwnTone 28.6

hacketiwack commented 1 week ago

I deployed the version 28.6 of the official containerised version of OwnTone. This version is available here.

Depending on which version you are using it can be that it is using older versions of JavaScript libraries. This can be the issue.

On my iPhone mini 13, the menu is showing up with the version 28.6 and the subsequent version, it works fine.

Where do you get the installation package of OwnTone for your deployment? On what machine is it deployed? Is containerisation an option for you? I would highly recommend using Podman (recommended) or Docker on your machine?

hacketiwack commented 1 week ago

Could be also worth upgrading your iOS version to the 17.5.1 for security reasons.

pisabird commented 1 week ago

Hello Hacketiwack,

No, you misunderstand. Version 28.6 is fine for me, but there is a problem with

[2024-06-26 13:44:57] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached.

I don’t update to the next version of OwnTone due to the problems with the speaker button on Safari.

I use OwnTone on my Proxmox LXC Container Debian 11.

Is there a possibility to get the fix from @ejurgensen for 28.6?

I am very happy with my current iOS version. All the others have new designs and functions that I don't like. There is also a big change regarding the EU law that might not work for me.

Thank you everyone for your great support.