Not sure if this is new to 1.6 but I have a mDNS bellowing to roonserver and also one to avahi. mDNS only supports one instance. Is it possible to disable the one in roonserver?
Thank you for reaching out. Currently there is no way to disable mDNS in Roon. May I ask that you please elaborate a bit on your current Roon and networking setup? I am going to speak with the development team about this during our meeting this week and this additional information will help to provide to make sure they have everything they need.
For what it’s worth, I have Avahi running on my Roon Core (running on CentOS 7) and I haven’t observed any conflicts between Roon 1.6 and Avahi. Neither appears to open the mDNS port in exclusive mode, and since it’s UDP, they can both share the port.
I am running the current version of Fedora with zfs, netatalk and avahi as core services. On this I have installed Plex and Roon Server. The Linux box is my backup server for three Macs which mount the Linux ZFS volumes using netatalk and rely on avahi for name resolution.
This ran smoothly until around the time of the 1.6 upgrade when name resolution on the Mac side started getting flakey and the backups failing as a result. When I investigated the server it showed mDNS launched by both netatalk and roonserver. I have disabled avahi for the time being but losing name services makes the backups more difficult to manage.
Let me know if you need more information.
Thank you for the info, @pwright92. I’ll be sure to update you here once I have discussed this with the team.
I met with the team to discuss this and I wanted to reach out regarding that discussion.
First, the team spoke a bit about the changes made in version 1.6. There were some changes made to how we handle responses, but no other changes regarding how mDNS is used by Roon that would impact Avahi’s performance here. Based on the conversation I had with the team, there is nothing Roon, or specifically the 1.6 update, that should cause any interference here.
The team was hoping to get a little more information from you about how Roon seems to be impacting Avahi. Can you provide some specifics about what you’re seeing here?
If you stop RoonServer does the problem with Avahi go away?
I disable avahi and have been using IP addresses for my backups. When I re-enable avahi, I get the following status:
[root@mercury ~]# systemctl start avahi-daemon.service
[root@mercury ~]# systemctl status avahi-daemon.service
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2019-02-04 16:07:39 EST; 23s ago
Main PID: 19578 (avahi-daemon)
Status: “avahi-daemon 0.7 starting up.”
Tasks: 2 (limit: 4915)
├─19578 avahi-daemon: running [mercury.local]
└─19579 avahi-daemon: chroot helper
Feb 04 16:07:39 mercury avahi-daemon: No service file found in /etc/avahi/services.
Feb 04 16:07:39 mercury avahi-daemon: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Feb 04 16:07:39 mercury avahi-daemon: Joining mDNS multicast group on interface enp4s0.IPv6 with address fe80::66da:ac19:bc02:ad47.
Feb 04 16:07:39 mercury avahi-daemon: New relevant interface enp4s0.IPv6 for mDNS.
Feb 04 16:07:39 mercury avahi-daemon: Joining mDNS multicast group on interface enp4s0.IPv4 with address 192.168.0.210.
Feb 04 16:07:39 mercury avahi-daemon: New relevant interface enp4s0.IPv4 for mDNS.
Feb 04 16:07:39 mercury avahi-daemon: Network interface enumeration completed.
Feb 04 16:07:39 mercury avahi-daemon: Registering new address record for fe80::66da:ac19:bc02:ad47 on enp4s0.*.
Feb 04 16:07:39 mercury avahi-daemon: Registering new address record for 192.168.0.210 on enp4s0.IPv4.
Feb 04 16:07:40 mercury avahi-daemon: Server startup complete. Host name is mercury.local. Local service cookie is 94870290.
If I run the backups against the mercury.local target rather than the IP address, I will get about 10% of the mount requests from my Mac failing. I was previously running on Debian without an issue so this may be toed to Fedora. I moved from Debian to Fedora because I had stability issues related to using a first generation Ryzen chip.