· None of the above quite fits
· None of these quite match
· Playback through Roon frequently stutters with messages like 'Tidal media is loading slowly'. This happens whether Tidal, qobuz or local files. I don't have any problems when using Tidal or Qobuz Connect.
· FRITZ!Box 7530 AX
Hi @herewego,
Thank you for your post.
We see several dropouts in logs over the last week, affecting a FiiO and an Eversolo endpoint primarily. It’s worth noting that this affects both 96Khz and 48Khz playback from what we can tell, and as you mentioned, both streaming and local tracks are affected.
The Qobuz dropouts are caused by inadequate connection bandwidth between Roon Server and the Qobuz API serving content to Roon. In most cases, a 96Khz stream falls just below the kbps required to keep up with playback:
08/06 13:59:54 Warn: FTMSI-B-OE qo/CD3BF4E7: poor connection kbps:5456.0 (min:6290.0)Other dropouts occur because samples are dropping off the network before they reach endpoints, and Roon Server can’t send them fast enough to recover the endpoint buffer.
Where is your server machine connected relative to the main router? Do you have multiple mesh nodes/access points? The more information you can share about your topology, the more equipped we’ll be to assist with granular steps.
In the meantime, try forcing a max sample rate of 48Khz as a temporary test and let us know if this reduces the frequency of dropouts.
We’ll watch for your reply. Thank you!
Hi
Thanks for your message.
Where is your server machine connected relative to the main router? Do you have multiple mesh nodes/access points? The more information you can share about your topology, the more equipped we’ll be to assist with granular steps.
The main Fritzbox is close to the ONT box. A 5m cable runs to a network switch. The Roon server is connected to that switch, as is another Fritzbox acting as another access point.
The Fiio and Eversolo connect to the network by wifi.
In the meantime, try forcing a max sample rate of 48Khz as a temporary test and let us know if this reduces the frequency of dropouts.
Am i right to think that I do this in the device setup / advanced settings in Roon for each endpoint?
Thanks
Hey @herewego,
You can also access your MUSE/DSP settings for each zone:
Let us know if that changes the behavior at all. Thank you! 
Hi
This seemed to help yesterday playing music through the Fiio. However I’ve just tried to play In a Silent Way through the Eversolo and playback again stuttered then stopped.
Can you give me an idea of what the cause of this behaviour in Roon is? Somewhere above it is mentioned that there is “inadequate connection bandwidth between Roon Server and the Qobuz API serving content to Roon”. I’m assuming this is an issue with Roon, given that there are no issues playing back the same content using Tidal Connect or Qobuz Connect. Is that correct?
Also can’t play In a Silent Way through the Fiio - again it stutters, stops and goes to the next queued track.
Hi @herewego,
Thanks for your patience, and thanks for pushing back, your question about Tidal Connect is a fair one, and it deserves a proper answer rather than us just pointing at bandwidth again.
I’ve gone back through your logs from the 24th July through to yesterday, and I think we’ve been looking at only half the picture. Let me split it into the two things I’m seeing.
First, the honest answer on Tidal Connect
The comparison isn’t quite apples to apples. With Tidal Connect, your Eversolo fetches the stream itself and buffers it for a good stretch ahead of playback, so it can ride out a connection that’s slow or bursty without you ever hearing it. Roon works differently: the server fetches the audio and delivers it to your endpoint as a tightly clock-synced real-time stream. That gives us bit-perfect multi-room sync, but it’s much less forgiving of a connection that can’t keep ahead of the music.
So yes, a connection can be perfectly fine for Tidal Connect and still be marginal for Roon. That’s a real difference in how the two work, and it isn’t something you’re doing wrong.
Second, and more importantly, there’s something else going on
Here’s what changed my thinking. On the 10th of August, your FiiO dropped out repeatedly while playing local FLAC files from your own SSD, with the buffer sitting at 100% full:
08/10 15:44:19 [Fiio SR11] [24/48 FLAC => 24/48] [100% buf] [PLAYING @ 0:33/0:52]
/Volumes/SN850X 1TB/music/.../01 Opening.flac
08/10 15:44:20 Too many dropouts. Killing streamNo Qobuz, no Tidal, no internet involved at all, the music was already in memory on the Mac. Across the whole log period, 11 of the 19 stream failures happened with a completely full buffer. That can’t be an upstream bandwidth problem, and it means there’s a second issue between your Mac and your endpoints that we haven’t addressed yet.
I also see 18 clock sync failures to the FiiO, one of which killed a track two seconds after it started with a full buffer — then skipped to the next track, which sounds exactly like what you described.
What I’d like you to try, in this order
1. Turn off Wi-Fi on the Mac running Roon Server. This is my top suspect. Your logs show the Mac has two network connections active on your home network at once , Ethernet and Wi-Fi, both on 192.168.178.x , and Roon is advertising itself on both:
[ipaddresses] FOUND en0 192.168.178.69
[ipaddresses] FOUND en1 192.168.178.61When a server is connected twice like this, Roon can end up discovering an endpoint over one connection and streaming audio over the other. It produces dropouts and sync failures that look just like bandwidth problems but aren’t. Please switch Wi-Fi off entirely on that Mac (not just disconnect, turn the adapter off), keep the Ethernet cable, and restart Roon Server.
2. Change your streaming quality settings, not the DSP setting. I want to correct something I told you earlier. Forcing 48 kHz in MUSE/DSP only changes what leaves your server heading to the endpoint. Roon still downloads the full-size original file from Tidal or Qobuz, so the demand on your internet connection doesn’t change at all. That’s why it helped with most albums but did nothing for In a Silent Way, that one is a 24/176.4 file needing a sustained 7.3 Mbps, and I can see it failing on both your endpoints on the 12th and 13th.
The setting that actually reduces what gets downloaded is in Settings → Services:
That drops the requirement from around 7.3 Mbps to about 1.4 Mbps. Since everything is being converted to 48 kHz on output anyway, you won’t lose anything audible.
At the same time, please remove the sample rate conversion from MUSE/DSP, so we’re only changing one thing and not hiding the result.
3. Then test In a Silent Way again, on both the FiiO and the Eversolo, and let me know what happens.
A couple of questions while you’re at it
curl -o /dev/null -w "%{speed_download} bytes/sec\n" https://speed.hetzner.de/100MB.binIf that comes back around 700,000 bytes/sec while your browser speed test shows much higher, that points at your ISP or the FRITZ!Box rather than at Roon, and we’ll know where to go next.
Let’s start with switching off that Wi-Fi adapter, as I think that one may explain more than we assumed. 
Hi @benjamin
Thanks for the reply.
I’ve switched off:
I’m currently 7 minutes into In a Silent Way, which is further than I have got before! So I am hoping we have a fix - thank you. I’ll get back to you if the problem reoccurs but it seems good for now.
thanks again
Alex
ps Incidentally, the download test would not run. It returned the message:
0curl: (6) Could not resolve host: ``speed.hetzner.de
I had a quick Google and look at hetzner.de but couldn’t see an obvious way to fix this.
Hello @herewego
Three days on, how is it holding up? If In a Silent Way and the rest are still playing through, we would call this one solved.
On the speed test, nothing is wrong with your DNS. The backticks from the forum formatting were copied into Terminal along with the command, which is why it could not resolve the host. No need to chase it now, but that is all that was.
If you would like Lyrion back, please turn it on and see whether things stay stable. If they do, keep it. If the stutter returns, we will know where to look.