owntone-server
owntone-server copied to clipboard
owntone
AirPlay Outputs disappear
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...
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).
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 [email protected] 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.
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 [email protected] 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.
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.
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.
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 [email protected] 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.
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.
Thank you!
On Feb 25, 2018, at 03:59, ejurgensen [email protected] 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.
Now I changed my ATV to Ethernet, and I tried the following:
- disconnecting the ATV, waiting for the timeout, and then reconnecting
- disconnecting the server (also wired), waiting for the timeout, and then reconnecting
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:
- Set the log level to debug and see if there are any related messages about the devices after the resolver timeouts
- Could you set up some sort of ping to see if there is connection interruption? It would be approx 3 minutes before you see the timestamp of the timeout message.
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!
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.
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.
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?
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.
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.
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.
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.
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
- eth0 IPv4 EF13831FCBBB@Lavanderia _raop._tcp local
- eth0 IPv4 D0034B1A8C67@AppleTV _raop._tcp local
- eth0 IPv4 5453ED14C3D8@SONY _raop._tcp local
- eth0 IPv4 000C8A575193@Bose _raop._tcp local
- eth0 IPv4 857E66F85A32@Ospiti _raop._tcp local
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.
[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
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.
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
"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.
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
- eth0 IPv4 857E66F85A32@Ospiti _raop._tcp local
- eth0 IPv4 EF13831FCBBB@Lavanderia _raop._tcp local
- eth0 IPv4 000C8A575193@Bose _raop._tcp local
- eth0 IPv4 D0034B1A8C67@AppleTV _raop._tcp local
- eth0 IPv4 5453ED14C3D8@SONY _raop._tcp local
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
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 !!
The problem is still there. I have a Raspberry Pi running forked-daapd and 3 outputs:
- HomePod via AirPlay
- Apple TV 4 via AirPlay
- 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.
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?
@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
_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?..