· 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.
Yes, we can pull them. What we need from you is a timestamp, because these stalls last well under a minute and the logs cover a lot of ground.
Next time it happens, please note the date, the clock time and your timezone, the track, and whether it was Qobuz or Tidal. That lets us go straight to the right few seconds and see which request stalled. Two or three events would be better than one, since a pattern tells us more.
Please also confirm whether the DNS change went in, so we know which setup we are looking at.
IPv4 only is exactly right, and it is all you need. You turned IPv6 off, so there is nothing for it to set. The DNS fields are in the same place as the IP address settings, at the bottom of that window, which is easy to miss.
On Windows 11 the simplest route is:
Settings, then Network & Internet.
Click the connection you are using, Wi-Fi or Ethernet.
Find DNS server assignment and click Edit.
Change Automatic (DHCP) to Manual.
Switch IPv4 on.
Preferred DNS: 1.1.1.1
Alternate DNS: 1.0.0.1
Save.
If your machine shows the older dialog instead, it is the same fields in a different place:
Control Panel, then Network and Sharing Center, then Change adapter settings.
Right-click your connection, choose Properties.
Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
At the bottom of that window, choose Use the following DNS server addresses and enter the two values above.
OK, then Close.
Leave the IP address settings alone in either case. Only the DNS boxes change.
Then restart Roon Server and carry on as normal. When it next stalls, please send us the date, the clock time with your timezone, the track, and whether it was Qobuz or Tidal.
Wanted to follow up on this. Have you had a chance to switch your DNS to the Cloudflare values we mentioned, with IPv4 turned on and the IP address settings left alone? After that, we asked you to restart Roon Server, and when the issue happens again, to send us the date, the exact clock time with your timezone, the track, and whether it was from Qobuz or Tidal. Let us know what you’re seeing, and we can take it from there.
Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.
.