· So this weekend I’ve noticed strange behavior with Qobuz and sometimes tidal. When I I’m streaming an album it will often pause and then not play. Then I get message “Track not available from Qobuz”. But the track is indeed available. I don’t think it’s my network since everything else is streaming well. Mostly been issues with Qobuz, but it just did with Tidal that I had to switch out to use Connect (as I restart my server again).
Thanks for the detailed report! We were able to review a set of fresh Roon Server logs from your Server machine, and they told us exactly what’s going on. The good news is your instinct is right: the tracks really are available. This isn’t a Qobuz catalog problem.
When you start a track, Roon Server asks Qobuz for the streaming URL. During your listening sessions this weekend, some of those requests hung and got canceled after timing out, and Roon reports that as “Track not available from Qobuz.” The track is fine, Roon just didn’t get a response in time, so playback stalls.
A couple of details point us away from Qobuz and toward something on the network path out of your server:
The same kind of stall shows up on Tidal and even Roon's own servers in your logs, not just Qobuz, which lines up with the one Tidal hiccup you mentioned. Qobuz just takes the brunt because your library relies on it heavily.
When a URL did come back, the actual audio streamed fine, so your streaming bandwidth is healthy. It's specifically the small "handshake" requests that are stalling.
That combination, some quick API calls hanging completely while others on the same service succeed instantly, usually comes down to IPv6, DNS, or the router. I'd try these in order:
Disable IPv6 on the machine running Roon Server (or at your router) and test. This is the most common cause of this exact pattern.
Set your DNS to 1.1.1.1 or 8.8.8.8 instead of your ISP's default.
Reboot your router (not just the server), and if you have any "smart QoS," SQM, or deep-packet-inspection features enabled, try turning them off temporarily.
Restarting the server helps for a while because it clears the stuck connections, but it'll come back until we sort out the path issue, so those three steps are where I'd focus.
Let me know how it goes after trying them, and if it’s still happening, tell me which step you got to and we’ll keep digging.
Hey Benjamin, So far I’ve disabled the IPv6 tonight I’ve gotten no issues. I will test throughout the week and Friday night will have a much longer listening session along with Saturday.
Trying to hunt the DNS settings. Im glad you were able to narrow down to my network .
Glad to hear that helped. Disabling IPv6 looks like a promising change, and it’s good to hear you’re going to keep testing through the week and then give it a longer listen on Friday and Saturday.
Once you’ve had that extended session, please let us know how it goes. If the issue stays quiet, we can treat that as a strong sign we’ve found the right path.
Will say it happened once with one song but waited a bit to load then it played. I was digging through the settings DNS is quite confusing. Is it supposed to be 1.1.1.1. Per device?
The other settings are showing such as Smart QoS, SQM and deep packet. Apparently these networks operate way differently than other ISPs.
A couple of tracks did it tonight. I also paid more attention to how long it will take for this to occur. It will be a min then like you said jump to the next track. But if I go back using the buttons it will load mostly using Qobuz today.
Thanks for sticking with the testing, this is still useful data even with it recurring less often.
On DNS: setting it at the router level is the cleaner option since it applies to every device on your network consistently, but what actually matters most here is the Roon Server machine specifically, since that’s the one making the Qobuz and Tidal requests. If per-device is easier for you right now, that’s fine too, just make sure it’s set on the server. For the actual values, Cloudflare’s pair is 1.1.1.1 and 1.0.0.1, or Google’s is 8.8.8.8 and 8.8.4.4, either works.
Since Smart QoS, SQM, and deep packet inspection are all still enabled on your end, that’s likely the remaining piece. Verizon’s Home Internet gear is known to do some fairly aggressive traffic shaping, and deep packet inspection in particular can interfere with exactly this kind of short API “handshake” call stalling out, while the actual audio stream keeps working fine. Disabling IPv6 helped reduce it, which fits the pattern we expected, but there’s likely a second contributing factor here.
Could you please turn off Smart QoS, SQM, and deep packet inspection, along with the DNS change, and keep an eye on it over the next few days the way you’ve been doing? If it clears up completely, we’ll know it was the combination of the two. If it’s still happening after all three changes are in place, let us know and we’ll take a closer look at the logs from that point.
Based on what I’m reading I can’t disable the features. I’ll follow up on the DNS though.
The Verizon Internet Gateway (WNC-CR200A) does not feature user-accessible settings to disable Smart QoS, SQM (Smart Queue Management), or deep packet inspection/switching. Its firmware locks down advanced WAN and traffic-shaping controls.
Thanks for keeping us posted. Even with the issue recurring less often, the extra testing has still been useful data.
Please go ahead with the DNS change and keep an eye on performance over the next few days. We also recently updated Roon, so please make sure you’re on the latest version to pick up the latest performance improvements.
So it has been happening a bit here and there even with Tidal. Not sure if you are able to check the logs? But it was not as frequent as prior since removing ipV6.
.