Topology: AT&T fiber -> Ethernet converter -> AT&T router -> main Deco AP, then WiFi to get upstairs (5GHz backhaul), second Deco AP -> Ethernet to my Nucleus, and Ethernet to my miniDSP SHD endpoint. Back downstairs, from the main Deco AP, WiFi to an iMac running Roon.
The Nucleus is v1.0, build 259 Roon Server Software (on the Nucleus) is v2.66 build 1658 I don't see the versions on the endpoints, but they can't be too old. I update everything every time an update is available.
The issue: Playback drops on both endpoints, and if I test on my Macbook or iPad (which I don't typically use as endpoints). When it drops I get a "Qobuz media loading slowly" message. Qobuz is my only streaming service. Playing from my local library (external SSD plugged into the Nucleus) does not have any problems.
Troubleshooting started with rebooting everything listed in the chain above, from the fiber to Ethernet converter to the Nucleus and endpoints. No change. Testing my Internet connection - consistently around 300Mb down, and TV, etc is all fine, so that's not it. QoS on my network has always been applied to the Nucleus and SHD.
To continue gathering info, I've been using the Qobuz web player for a while. I'm connected to the main Deco via WiFi, and streaming from Qobuz without issue.
Summary: Roon is fine from the local library and Qobuz is fine from their web player. But Qobuz via Roon isn't working well.
Thanks for writing in and for sharing your report! Sorry to hear about your Qobuz issues.
You mentioned QoS is applied to the Nucleus and SHD. QoS rules can throttle or shape traffic in ways that interfere with streaming, even when total bandwidth seems fine, especially if the rules are shaping HTTPS traffic to Qobuz’s CDN differently than your Mac’s traffic. Temporarily disable QoS on your router/Deco entirely and test Qobuz via Roon. If the drops stop, QoS is the culprit and you’ll need to reconfigure it (or remove it — the Nucleus doesn’t actually benefit from QoS the way a VoIP phone would).
I would also test out assigning static IPs to both the Nucleus and the SHD in the Deco app.
And lastly, your Roon Server diagnostic report shows the Nucleus is upsampling Qobuz 24/44 FLAC to 32/384 for the iMac zone (Enhanced DSP at 13-14x) and to 24/192 for the miniDSP zone. That’s a significant processing and bandwidth load. Try disabling DSP upsampling temporarily and playing native quality, this will tell you whether the Nucleus’s outbound bandwidth to the endpoint is a factor.
Thanks for those tips. While I was in the Deco app earlier, it suggested that I reduce channel width from 160 to 80 (I don’t know what this means, it’s just what the Deco app said) for compatibility reasons. I did that, but then it complained that my network wasn’t optimized, and I should change channel width back to 160. I did, so no net change in the end. Except Qobuz has been fine sense then. I don’t know if that’s a fluke or if something was “Reset” in that process…
I did turn off QoS for the Nucleus (and I will for the SHD later when it’s not in standby). I also confirmed that the Nucleus already has a static IP. I did that back when I set up Arc. Should I add a static IP for the SHD but not the iMac? Or both? You only mentioned the SHD, but it seems like it would apply to both.
I had Sample rate conversion set to Max PCM rate for the iMac (I don’t recall for the SHD - probably the same, I’ll check it later). I turned it off for the iMac. I think I only had that on because I’m a typical bafoon. If you give me knobs, I’ll turn everything up to 11.
I’ll leave it running like this for a while and if there are no more issues, I’ll forget about it and just enjoy listening to music.
It sounds like you’ve made some excellent progress! Sometimes the simple act of “re-applying” a network setting (like toggling that channel width) forces the Deco mesh to re-negotiate its internal connections, which can clear out stale ARP tables or weird routing ghosts in the machine.
Regarding the 160 MHz channel width: You are correct to be curious about it. In a perfect, interference-free environment (like a standalone house with no neighbors), 160 MHz provides massive throughput. However, if you are in a multi-unit building or a dense residential area, it is extremely susceptible to interference from neighboring networks and DFS (Dynamic Frequency Selection) radar events.
If you notice the “media loading slowly” messages return, the first thing I would suggest is dropping back to 80 MHz. While it sounds like a “downgrade,” it is often significantly more stable for streaming because it is less prone to the drops caused by channel congestion and interference.
To answer your question about static IPs: You are absolutely right—applying them to all your Roon-critical devices (Nucleus, SHD, and iMac) is a best practice. It ensures that if the router reboots, the devices don’t “jump” to new addresses, which keeps your RAAT connections stable and your port forwarding rules (like those for ARC) intact.
Go ahead and enjoy the music for now! If the drops come back, drop the width to 80 MHz, and you should be good to go. We’ll leave this thread open for a few days to make sure you’re fully satisfied before marking it as solved. Happy listening!
@vadim - thanks for the additional insight. It’s been solid ever since removing upsampling. Downstairs, at least. I’m not streaming upstairs lately - just records. Downstairs is where it was more problematic, though, so if it’s working downstairs, it’s solved. I’ll mess with upsampling again, but I’m not sweating it.
I did, so no net change in the end. Except Qobuz has been fine sense then. I don’t know if that’s a fluke or if something was “Reset” in that process…
