What kind of performance/speed issue are you experiencing?
· The app is crashing
Please try to reboot your Roon Server
· No, the issue is still the same even immediately after a reboot
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 don't know how to do this
What is the operating system of your Roon Server host machine?
· MacOS
Timestamp of issue occurrences
· 17 August. Midday.
Describe the issue
I have managed Unifi network. I run Roon Server on a M2 Pro 16gb. It is connected to the Unifi switch. I have multiple wireless zones. I am trying to play an album from Qobuz to my office zone. It plays about 10 seconds, stutters, stops, skips to the next track. Happens repeatedly and consistently. Have deleted and reinstalled Roon. No change. Hopeless. I also have an Innuos streamer connected to the same switch, which I use in my main hifi system. Using the Innuos Sense app (not the Roon endpoint) via uPnP I can play the same album from Qobuz to the same zone (as it does Roon Ready and uPnP) perfectly. So it's not my network, and as the Unifi app confirms excellent signal strength. I have turned off on-demand and background analysis. Please advise.
Describe your network setup
Unifi managed network. See main comment. One switch, multiple access points. It works perfectly with other audio systems.I've been Roon lifetime for perhaps 10 years, this network was installed in 2021, has up to 100 IPs running, never an issue, Roon never previously a problem. There is nothing else running in the M2 Pro.
Thank you for your post. We’ve pulled diagnostic logging from the affected Roon Server instance to inspect these failures. Here’s what we see happening:
The failures are isolated to one endpoint, the Lumisonic at 192.bbb.a.171 serving your Office zone. Every other Zone in the setup logs playback cleanly, including the Lumisonic at 192.bbb.a.244, which streamed Qobuz 24/88.2 continuously for 15 minutes in the same window. The Qobuz side is also logged as healthy: the CDN returns full files and Roon’s buffer is at 100% at the moment each track drops. The audio connection to the problematic Zone (.171) stalls and is torn down, and we also see the unit drop off and re-register twice. It fails at both 96kHz and 88.2kHz, but the one 48kHz stream ran without issue.
RAAT is uncompressed and will expose WiFi vulnerabilities other protocols might not reveal. We’ll need to know a little more to offer specific recommendations for this setup. Specifically:
Is any UniFi bandwidth limit or User Group profile applied to the SSID or client for .171?
Which access point serves .171, and is that AP wired or on a wireless mesh uplink?
This Zuma group is 4 devices. The main unit was .171, I did a restart and it transferred to .244, then back to .171 which was necessary because the bezel with Alexa was attached to that and needs to be on the primary. I tried again with the primary unit now .154. I’ll leave it there. The Alexa bezel is removed.
I also rebooted the AP. It’s pretty hot, so I’ve taken it off the wall, will let it cool a bit, and reattach. All the 4 Zuma devices are fixed to that AP.
All the AP’s are wired. Mesh is disabled.
The Roon Server is on ethernet but the wifi was on. I’ve turned it off.
“Is any UniFi bandwidth limit or User Group profile applied to the SSID or client for .171” I don’t know what that means, but I’ve got 25 of these units and I’ve not set anything.
I reattached the AP and the units are connected to other AP’s with much lower signals, but it’s sounding much better. See below - the signal is usually -45 to -55 give or take.
I’ve power recycled (the office power switch is on a Shelly relay) and hopefully I’ll get them to reconnect to the Office AP with a strong signal. It sometimes takes a bit of time for the switch to do what it’s told regarding AP fixes and then report correctly in the app.
It does seem the problem was having the wifi alive on the Roon Server.
If you want to check, it’s been on .154 for a while and I’ll leave it there.
I must say, I’ve had my Unifi network for 5 years (24 port + 2 x SFP 95w PoE switch and 5 AP’s). I have 25 or more wireless Roon Ready audio devices working at up to 24/192 PCM and it’s never let me down.
Apple let me down by an update switching on the wifi.
The Wi-Fi was not it. Your Mac has been reachable on two addresses, 192.168.1.64 and 192.168.1.73, continuously since 17 July, and it still is as of this afternoon. Whatever you switched off, the second address is still there today, while everything plays perfectly.
Today your office zone played all day with no errors at all. Across the 33 days we have logs for, every failure sits in one afternoon, 17 August. There is nothing on any other day.
So something specific went wrong that afternoon and has not come back. Our logs show what it was not: Qobuz returned complete files, Roon’s buffer was full at the moment each track dropped, and every other zone played cleanly throughout. Nothing was short of data, and your network was not slow.
The one thing that changed on the day and is not accounted for is the access point. You found it hot enough to take off the wall, let it cool, and rebooted it. That is our first suspicion, and it fits the shape of this better than anything else, though we cannot prove it from here.
