Qobuz tracks pausing or stopping unexpectedly (ref#0EAMAQ)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Other

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 was able to change my router's DNS servers but it did not help

What is the operating system of your Roon Server host machine?

· Roon Optimized Core Kit (ROCK)

Timestamp of issue occurrences

· 12:25 PT on Saturday, 6/6 (and many other times)

Describe the issue

Qobuz tracks just pause for a few seconds, or stop altogther

Describe your network setup

Xfinity, Eero 7 Pro, 1GB plan, all devices connected through ethernet, Cloudflare and Google DNS

2

Following up on this: Much more stopping and skipping songs around 2:45 to 2:50 PT (and still going) today.

3

Hi,

Thank you for the detailed report and for providing your logs — they gave us a clear picture of what’s been happening. We found several distinct issues across June 6, and I want to walk you through each one.

1. Qobuz tracks failing to load (around 10:00–11:24 AM PT on June 6)

We can see in the logs that Roon was successfully starting to download the next track from Qobuz’s streaming servers (Akamai CDN), but partway through the pre-buffer the server returned an error code indicating the file was no longer accessible. Roon retried with a fresh streaming link and got the same error again. This caused tracks to be skipped or fail to start.

This type of error originates on Qobuz/Akamai’s side — your network was delivering responses correctly. It points to a transient issue with Qobuz’s CDN that morning rather than anything in your setup.

2. Playback stopping around 12:25 PM PT on June 6 (matches your timestamp)

At almost exactly the moment you reported, we see your Marantz CINEMA 40 lose its network connection — and simultaneously, several other devices on your network also dropped off (WiiM Pro Plus, two Sony BRAVIA TVs, and others). Because all of these happened at the exact same second, this points to a brief upstream network interruption — most likely a momentary blip from your Eero mesh, router, or ISP — rather than a Roon issue. Roon dissolved the grouped zone because the CINEMA 40 dropped out, which stopped all playback.

3. Repeated track skipping from ~2:45–2:50 PM PT on June 6 (matches your follow-up)

This is the most technically interesting one. At 2:45 PM, a new track (“You’re the One” by Dwight Yoakam, in 24-bit/192kHz FLAC from Qobuz) started playing. Within 3 seconds it stopped with an error, then the next track did the same, and the next — each one skipping after just a few seconds, repeating about every 24 seconds for several minutes.

What we found: the Roon server was trying to send audio data to your Bedroom Bluesound NODE 2i, but the NODE’s internal buffer overflowed and couldn’t keep up. This happened because a brief network disruption (your MacBook Air remote disconnected at that exact moment) caused the streaming connection to drop and immediately reconnect, flooding the NODE with a burst of buffered audio data faster than it could absorb it. This is most severe with very high-bitrate content like 24/192 FLAC — lower resolutions (24/96 and below) have more timing headroom and are more resilient to this.

We also noticed something worth flagging: your Bedroom Bluesound NODE 2i has a significantly high clock drift (about −46 parts per million, or roughly −167 milliseconds per hour). A healthy device should be under 5 ppm. This level of drift makes the NODE less stable in grouped playback and more prone to the kind of buffer overflow described above. We’d recommend:

  • Checking for a firmware update on that NODE
  • If the issue persists, performing a factory reset on the Bedroom NODE 2i

Summary and next steps

Time (PT, June 6) What happened Likely cause
10:00–11:24 AM Tracks failing to open, IoFailure Qobuz/Akamai CDN returning errors server-side
12:24–12:25 PM All playback stopped Brief network interruption — multiple devices dropped simultaneously
2:45–2:50 PM Repeated track skipping every ~24 sec RAAT buffer overrun on Bedroom NODE 2i after network disruption; worsened by high clock drift on that device

A couple of things that may help going forward:

  1. Bedroom Bluesound NODE 2i: Please check for firmware updates in the Bluesound app and consider a factory reset if the skipping continues. The clock drift on this device is abnormally high and contributes to instability.
  2. Eero mesh: The simultaneous multi-device drop at 12:25 PM suggests brief upstream network interruptions. You may want to check your Eero logs or contact Eero/Xfinity support to see if there were any events around that time. IGMP snooping settings on Eero can also sometimes affect multicast-based device discovery.

Please let us know how things go after checking the NODE 2i firmware, and don’t hesitate to reach out if the skipping continues.

4

Wow Vadim–your response is awesome. I truly appreciate it. It seems that, in a nutshell, the issues were 1) the ongoing server issue that Qobuz is working through, 2) a network blip of some sort on my end, 3) and something weird (“clock drift”) happening with my Node 2i. Am I getting this right?

Regarding #3, the firmware is current, so I’m not sure what’s going on. Bluesound recently had an update, and I applied that to my devices. Perhaps I was in need of some reboots after recent updates from Roon, Bluesound, and Eero (which I’ve done). Things have been smoother since the original support request, but I’ll definitely do a factory reset of the 2i if these problems return.

This might be a question I’ll need to ask Bluesound, but in case you know, “audio clock trim” is turned off for all of my Nodes. It’s my understanding that it’s best to leave this off, but do you think it’s a relevant variable given my recent “clock drift” issue?

Thanks again for your very thorough reply!

5

Hello @JAM

You nailed it! That is a perfect summary of exactly what the logs were showing. It really was a “perfect storm” of three distinct, overlapping events.

Regarding your excellent question about the Audio Clock Trim setting in the Bluesound app:

You are completely correct that it is generally best to leave this setting Off, and it is actually entirely unrelated to the “clock drift” we are seeing in Roon.

Here is why:

  • Audio Clock Trim is a specific hardware setting that alters the timing bandwidth of the Node's physical digital outputs (the Coaxial and Optical ports). It exists strictly as a workaround for certain external DACs (like some older Schiit or Chord models) that have very narrow lock-in windows and stutter when receiving the Node's default digital signal.
  • Roon's Clock Drift refers to the internal system timer (the oscillator) on the Node's motherboard that Roon's RAAT protocol uses to synchronize music packets over your network.
Toggling the Audio Clock Trim won't fix the internal network timing drift, so leaving it disabled is exactly what you should do unless your specific external DAC is experiencing audio dropouts over optical/coax.

It is very possible that the recent slew of firmware updates from Eero, Roon, and Bluesound just needed those fresh reboots to finally settle in and sync up properly. If the Node 2i continues to behave itself, no further action is needed! Just keep that factory reset in your back pocket in case the skipping returns.

Enjoy the music, and please don’t hesitate to reach out if anything else pops up!