Open chesterdkat opened 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).
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.
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.
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 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.
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 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.
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:
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.
Hi @ejurgensen , OK thanks.... logs here:
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
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.
What does the log say? Set the log level to ‘info’ or lower.
[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.
Output 23091 (Ospiti) is enabled
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:
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?..
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.
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.
@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?
Sure, here is deb for Stretch: http://gyfgafguf.dk/temp/forked-daapd_26.3.75~rc4-2_armhf.deb
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...
Oh, sorry, looks like it was updated successfully. And wtf:
You remember I checked this manually with avahi browser and it was working with _airplay._tcp!
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.
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.
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
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?
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.
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.
What issue is that?
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.
Ok maybe @hacketiwack can do something about that
@pisabird what device are you using (I'm interested in the version of the web browser)? And which version of OwnTone are you using?
Hello hacketiwack
I am using iPhone mini 13 - Safari with IOS 16.6 - OwnTone 28.6
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?
Could be also worth upgrading your iOS version to the 17.5.1 for security reasons.
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.
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...