What kind of performance/speed issue are you experiencing?
· Tracks take a long time to play
Please try to reboot your Roon Server
· Yes, rebooting helps, but the issue returns after some time
Please try to reboot your networking gear (Router/Switches/etc.)
· No, the issue is still the same even after a reboot
Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?
· No, the issue is still the same
Does the issue happen on multiple Roon Remotes (controllers) or just one?
· Issue happens on multiple remotes
Router Domain Name System (DNS) change
· I was able to change my router's DNS servers but it did not help
What is the operating system of your Roon Server host machine?
· Roon Optimized Core Kit (ROCK)
Timestamp of issue occurrences
· around 18:20 local time while playing david lang album. several times during the last months
Describe the issue
Roon is slow, stops playback and sometimes looses all playback devices. This affects local library as well as Qobuz library. Setup has not changed over years so I would sort out general network related misconfigurations.
Describe your network setup
Fibre to home - Fritzbox Fibre - Ansuz Switch - ROCK - two Naim endpoints, one KEF endpoint, two roopiee endpoints, apple devices for control, Unify network
We have reviewed the Roon logs around the times you mentioned (18:55 and 18:57 local time), and they clearly show what is happening.
Roon Server is losing connection to your endpoints due to network routing and multicast issues (the logs show multiple “No route to host” and “Connection refused” errors at those exact timestamps).
Since your setup includes a Fritzbox, a Unifi network, and an Ansuz switch, this is likely related to how Multicast (mDNS) traffic is being handled or blocked over time.
To isolate the exact cause, I would recommend the following troubleshooting steps:
The Bypass Test (Isolating the Switch) Sometimes, specific network switches use flow control or energy-saving protocols that can eventually interrupt Roon’s device discovery protocol (RAAT). Please temporarily bypass the Ansuz switch. Connect your ROCK and at least one wired endpoint (e.g., one of the Naim devices) directly into the LAN ports of your Fritzbox.
Check Unifi Multicast Settings In your Unifi Network controller, please check the settings for your local network. Look for IGMP Snooping and Multicast DNS (mDNS). Depending on your exact Unifi topology, these settings can sometimes aggressively filter the traffic Roon needs to see your endpoints. Try toggling these settings (if they are currently ON, turn them OFF for testing, or vice versa).
Thanks. After turning off igmp snooping in the ubiquity network and a ROCK restart things seem to be better since 2 days. Will report back, if the issue arises again. I wonder how this can happen since I did not touch my setup for at least one year and things were going smoothly even with igmp enabled.
Many things can cause you a problems with network.
For example your router could have been updated with new firmware which has altered algorithm for IGMP Snooping feature. There are a lot more things to count other than this.
Let us know please if your set up is going stable or not after some time.
We have reopened this thread at your request. Can you please let us know the latest status on the issue, and please note the exact local time + date + track (if applicable), so that we can review diagnostics for your account during that time-frame? Thank you.
It happened around 21:00 local time today. Playing Nils Frahm - The Dog with 1000 faces. Around 8 or 9 minutes into the track. Playback stopped. All Audiozones (5) were gone and reappeared. I had to continue playback manually. Fresh install of roon on a brand new m2 last saturday, most recent roon version. First time since Saturday that the zones disapprared. System is not slow anymore, thought the five year old M2 was the culprit for that.
Again today around 8:58 local time all zones disappeared and reappeared without playing music. Besides fiive zones (2 Naim devices, 1 KEF device and two Ropiee devices) we have three iPhones ocassionally acting as audio zones.
Overall library browsing is significantly faster since hardware upgrade and software update, but the disappearing zones are annoying.
Thanks for the update! From a fresh diagnostric report, we can see The clearest failure is in the RAAT protocol messages.
On 05/04 at 20:48 local, the Naim ND 555 sent an explicit {“status”:“Lost”,“reason”:{“reason”:“standby”}} message mid-playback. The KEF LS50 Wireless II does the same thing repeatedly (04/28, 04/30, 05/01 twice, 05/02). This is not Roon dropping the devices, the devices are reporting that they’ve gone to standby of their own accord.
Actions:
On the Naim ND 555: in its settings, disable the automatic standby timer and disable the nightly auto-update/restart check, or schedule it for a time you're never listening. In Naim's app this is typically under "Standby Mode" or "Automatic Sleep."
On the KEF LS50 Wireless II: check KEF Connect app for sleep/auto-standby settings and disable them. The source_deselected reason suggests KEF is switching away from the Roon/streaming source — check if there's an automatic input switching setting.
Thank you for the detailed response, @benjamin ! However, this doesn’t fully address the issue. The KEF LS50 Wireless II is manually switched (e.g., for video calls), not automatically going to standby. The Naim ND 555 is always in auto-standby mode, so disabling its automatic standby timer isn’t relevant here. Additionally, the problem involves all five zones disappearing simultaneously, not just the two devices, and this is unrelated to turning off any single device. When the error occured last time during playback on the 555 all zones disappeared, but the 555 did not go into standby.
The behavior persists regardless of individual device states. In the past few days, I haven’t been able to observe the issue; I will provide an update in a week.
@benjamin Today 10:37 local time. Switching via remote frome ND555 radio input source to roon (Pharoa Sanders) playback does not start, all my zones disappeared. After about five minutes the zones reappeared, but I was not able to start playback. until 10:43. Please advise on a solution.
Thanks for the timestamp! From your description, we were able to pinpoint this timeframe from a fresh server diagnostic report.
Here’s what we see:
10:28:15 — The Wohnzimmer/ND555 zone finished its previous track naturally and suspended after 5 seconds of silence (normal behaviour)
10:28:24 — A remote client (your iPhone) reconnected to Roon Server, triggering a large "resume send" of 17,589 queued messages/state updates, a clear sign of a prior network dropout on the remote device
10:28:30 — Roon started playing Die drei ??? on Wohnzimmer/ND555 (started by a user on the iPhone)
10:37–10:43 — The ND555 (Wohnzimmer zone) was continuously and flawlessly playing Die drei ??? the entire time, with 5-second heartbeats and clean sync. No zone dropout, no error, no warning
10:40:08 — The Büro (KEF LS50) zone finished its track and suspended normally
10:44:44 — Someone on the remote initiated new playback (Martyn) for Büro zone, which started successfully
The zone disappearance you experienced seems to be specifically tied to the remote app, not a server-side event. The server never lost the zones.
It looks like this could be a WiFi/network related issue between your iPhone and the server, and not so much a Roon Server problem.
That, and an input source conflict on the ND555. When you switched the ND555 from its Radio input back to the Roon/streaming input at the hardware level (~10:37), Roon was already playing on that endpoint (Die drei ???). The ND555 had to re-negotiate its input, which causes a brief period where the RAAT connection handshake must re-establish. While the server logs show this was seamless on the server side, the remote app, already in a fragile state, could have shown the zone as unavailable or unresponsive during this transition.
A few areas to investigate further from this:
iPhone WiFi settings: make sure "Private Wi-Fi Address" isn't causing MAC rotation issues
Router settings: disable client isolation if enabled; ensure the iPhone and Roon Server are on the same subnet (not separated onto a guest network or different VLAN)
If you use a mesh WiFi system, the iPhone may be roaming between nodes and dropping the Roon TCP connection. Setting a persistent connection to a specific node, or enabling "band steering" properly, can help.
A follow-up question for you: are you switching the ND555's physical input externally and then trying to command Roon? If so, I would consider switching the ND555 to the Roon source first from within the Roon app (if using Roon Ready), which should keep the RAAT handshake clean.
Let me know if the above helps, thank you @sailorck
Thank You for Your detailed feedback. Unfortunately You are investigating the situation on the wrong day. The zones disppeared on May 14th around 10:37 Berlin time. Your analysis was on May 15th, on which I did not encounter problems. Could You please check again, @benjamin ? Thanks for the effort!
We’re unable to trace back diagnostic information that far back, unfortunately. If you can, please still run through the additional areas to investigate I’ve shared in my previous response, that would be helpful.
I’d also be curious - if you temporarily disable your Kef endpoint altogether, do you experience any issues?
Feel free to share a fresh track name the next time you experience the issue. Thank you!
