Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AirPlay Outputs disappear #496

Open
chesterdkat opened this issue Feb 23, 2018 · 53 comments
Open

AirPlay Outputs disappear #496

chesterdkat opened this issue Feb 23, 2018 · 53 comments
Labels
bug

Comments

@chesterdkat
Copy link

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
Copy link
Member

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
Copy link
Author

chesterdkat commented Feb 23, 2018 via email

@chesterdkat
Copy link
Author

chesterdkat commented Feb 23, 2018 via email

@ejurgensen
Copy link
Member

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
Copy link
Member

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
Copy link
Author

chesterdkat commented Feb 24, 2018 via email

@ejurgensen
Copy link
Member

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
Copy link
Author

chesterdkat commented Feb 25, 2018 via email

@ejurgensen
Copy link
Member

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.

@slimey
Copy link

slimey commented Mar 17, 2018

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
Copy link

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
Copy link
Member

ejurgensen commented Jun 17, 2018 •
edited
Loading

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.

@ejurgensen ejurgensen added the bug label Jun 17, 2018
@jshep321
Copy link

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
Copy link
Member

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
Copy link

jshep321 commented Jun 22, 2018 •
edited
Loading

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

@ejurgensen
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link

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.

@ejurgensen
Copy link
Member

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

@fmalfatto
Copy link

[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
Copy link
Member

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
Copy link

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
Copy link
Member

"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
Copy link

fmalfatto commented Nov 3, 2018 •
edited
Loading

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

@fmalfatto
Copy link

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
Copy link

aprosvetova commented Nov 15, 2018 •
edited
Loading

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
Copy link
Member

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
Copy link

@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
Copy link

@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
Copy link
Member

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

whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 26, 2018
@ejurgensen
[raop] Add option to make an Airplay speaker permanent in the speaker…
ee01953 
… list (issue owntone#496)
whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 26, 2018
@ejurgensen
[raop] Listen for _airplay._tcp and make it a condition for device re…
7a6a745 
…moval (issue owntone#496)
whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 26, 2018
@ejurgensen
[raop] Add option to make an Airplay speaker permanent in the speaker…
df343f3 
… list (issue owntone#496)
whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 26, 2018
@ejurgensen
[raop] Listen for _airplay._tcp and make it a condition for device re…
f76c731 
…moval (issue owntone#496)
@aprosvetova
Copy link

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
Copy link

aprosvetova commented Nov 27, 2018 •
edited
Loading

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
Copy link
Member

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
Copy link

aprosvetova commented Nov 27, 2018 •
edited
Loading

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.

whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 27, 2018
@ejurgensen
[raop] Add option to make an Airplay speaker permanent in the speaker…
e9551b1 
… list (issue owntone#496)
whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Nov 27, 2018
@ejurgensen
[raop] Listen for _airplay._tcp and make it a condition for device re…
7f1e635 
…moval (issue owntone#496)
ejurgensen added a commit that referenced this issue Dec 1, 2018
@ejurgensen
Revert "[raop] Listen for _airplay._tcp and make it a condition for d…
bb1347f 
…evice removal (issue #496)"

This reverts commit 1e05140.
whatdoineed2do pushed a commit to whatdoineed2do/forked-daapd that referenced this issue Jan 1, 2019
@ejurgensen
Revert "[raop] Listen for _airplay._tcp and make it a condition for d…
dd4650b 
…evice removal (issue owntone#496)"

This reverts commit 1e05140.
@ejurgensen ejurgensen mentioned this issue Apr 29, 2019
Closed
@brianegge
Copy link

brianegge commented Jul 22, 2021 •
edited
Loading

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

What issue is that?

@pisabird
Copy link

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
Copy link
Member

Ok maybe @hacketiwack can do something about that

@hacketiwack
Copy link
Collaborator

@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
Copy link

Hello hacketiwack

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

@hacketiwack
Copy link
Collaborator

hacketiwack commented Jun 27, 2024 •
edited
Loading

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
Copy link
Collaborator

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

@pisabird
Copy link

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.

@hacketiwack
Copy link
Collaborator

As I understand it, It does not have any direct connection to the web UI. All clear now.

@ejurgensen
Copy link
Member

ejurgensen commented Jun 27, 2024 •
edited
Loading

@pisabird you can't get fixes for already released versions. You wrote that "I don’t update to the next version of OwnTone due to the problems with the speaker button on Safari.", but it's unclear what those problems are. If you think there is a problem with the button then please add a new issue here on Github with a proper error description.

@pisabird
Copy link

Hello,

I am now on 28.9 and I have still the problems on my HomePodMini....

Jul 16 09:23:48 OwnToneSelbst owntone[128]: [2024-07-16 09:23:48] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached
Jul 16 09:26:42 OwnToneSelbst owntone[128]: [2024-07-16 09:26:41] [ LOG] mdns: Avahi Resolver failure: service 'F434F03DAABC@NodeRed' type '_raop._tcp' proto 0: Timeout reached
Jul 16 09:39:37 OwnToneSelbst owntone[128]: [2024-07-16 09:39:37] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached
Jul 16 10:59:46 OwnToneSelbst owntone[128]: [2024-07-16 10:59:46] [ LOG] mdns: Avahi Resolver failure: service 'F434F03DAABC@NodeRed' type '_raop._tcp' proto 0: Timeout reached
Jul 16 11:13:24 OwnToneSelbst owntone[128]: [2024-07-16 11:13:24] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached
Jul 16 11:18:58 OwnToneSelbst owntone[128]: [2024-07-16 11:18:58] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached
Jul 16 11:41:43 OwnToneSelbst owntone[128]: [2024-07-16 11:41:43] [ LOG] mdns: Avahi Resolver failure: service 'F434F03DAABC@NodeRed' type '_raop._tcp' proto 0: Timeout reached
Jul 16 12:13:56 OwnToneSelbst owntone[128]: [2024-07-16 12:13:56] [ LOG] mdns: Avahi Resolver failure: service 'F434F03DAABC@NodeRed' type '_raop._tcp' proto 0: Timeout reached
Jul 16 12:47:08 OwnToneSelbst owntone[128]: [2024-07-16 12:47:08] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached
Jul 16 12:52:51 OwnToneSelbst owntone[128]: [2024-07-16 12:52:51] [ LOG] mdns: Avahi Resolver failure: service 'NodeRed' type '_airplay._tcp' proto 0: Timeout reached

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@brianegge @ejurgensen @aprosvetova @slimey @fmalfatto @chesterdkat @jshep321 @hacketiwack @pisabird