Slow load times for tracks and app with ROCK server (ref#RQ3CDH)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Tracks take a long time to play

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

· I just logged three events, all on Sunday, March 15: 4:18:07PM; 4:23:30PM; 4:28:40PM, all in Central Time Zone.

Describe the issue

During playback, the load times for a new track can be several minutes long. For example, I just watched as a track took from 4:18:07 to 4:19:41 to load on Sunday, March 15(Central Time, track was Jon Hiatt Native Son). Initial app loading is also slow, taking what seems to be a very long time to load the home screen.

I am using a ROCK server which is connected via ethernet to a TPLink AX3000 router. The machine I am using at the moment is also connected to the router via ethernet without wifi. The controlling machine is a Mac Mini M2 (2023) with 16GB RAM.

Note that I am using local files only for this test, no Qobuz. The problem happens with Qobuz, too.

Describe your network setup

Xfinity ISP, TP LINK AX3000 router, a TP LINK Switch (TL105). The problem also happens with controllers on iPad, iPhone, and Android tablets using wifi.

2

Hello @Lanny_Hoff,

Thank you for the detailed report, the troubleshooting steps you’ve already taken, and the exact timestamps. Waiting two minutes for a local track to load is definitely not expected behavior.

To help our development team see exactly how the app interface is reacting during these long delays, could you please record a short video of the issue?

A quick screen recording showing the moment you click play right up until the track finally starts would be perfect. Seeing if the play button spins, the progress bar hangs, or the UI freezes provides vital context that logs alone can miss.

Since video files are usually too large to attach to the forum, please upload it to a cloud drive here : https://workdrive.zohoexternal.com/collection/nqcgjac23027d90a441bda2c314de49d7958a/external

We will keep an eye out for the link and match it up with your diagnostic logs!

3

I uploaded a video showing the issue. Note the following:

  1. When the next track starts to load, the time bar is doing scan-back and forth.
  2. When I click on the upcoming track name, the display goes back not to the last track, but two tracks previous.
  3. Keep watching and you’ll see me trying to hit the pause button and then the play button but nothing happens.
  4. Eventually, after more than 2 minutes, the waveform updates but not the artwork.
  5. The upcoming track (The Grand Duel), did start about 90 seconds after I stopped the video.

Overall, this issue is getting much worse, not better.

4

Hey @Lanny_Hoff,

Thanks for sending the video over! In addition, could you please access the webUI of your ROCK and share a screenshot of what you see? Here’s more info on how to access the webUI:

The “scan-back-and-forth” on the time bar often signifies that Roon is trying to “handshake” with the endpoint but isn’t getting a ready signal.

  • System Output Test: Try playing audio to the "System Output" of your Mac Mini or your iPad/iPhone rather than your main hi-fi DAC.
    • If it plays instantly: The issue is likely the network communication between Roon and your specific DAC/Endpoint.
    • If it is still slow: The issue is definitely at the Server/Database level.
Roon relies heavily on multicast traffic to keep remotes and servers in sync. Some TP-Link routers have features that can interfere with this:
  • Disable "Smart Connect": In your TP-Link AX3000 settings, ensure "Smart Connect" (which merges 2.4GHz and 5GHz) is off. Give them separate names to ensure your wireless remotes aren't jumping between bands.
  • IGMP Snooping: Look for this setting in the Advanced Network or IPTV tab of the router. If it is On, try turning it Off (or vice versa). This often resolves sync issues where the remote shows one track but the server is playing another.

Let me know if any of the above help, thank you Lanny! :folded_hands:

5

Hi Benjamin,

That’s good to know about TP-Link routers, it should be posted in the KB along with the other brand-specific info, and perhaps that section (Router Specific Settings) should be top-level?

6

Thanks, Benjamin. See screen shot attached.

Also have a problem with Roon ARC, another screen shot attached. I was thinking maybe this is all related which is why I include it here. Might be a separate issue but I wanted you to see it.

I’ve disabled Smart Connect in the router settings. For now I’m going to leave the IGMP to see how it progresses.

I’ll try output to System Output and report back.

Screenshot 2026-03-18 at 6.09.06 PM
Screenshot 2026-03-18 at 6.09.06 PM1222×982 68.3 KB

Screenshot 2026-03-18 at 6.08.22 PM
Screenshot 2026-03-18 at 6.08.22 PM963×584 56.2 KB

7

@benjamin outputting to system output on a Mac Mini that is connected to the ROCK via ethernet, I am still getting delays. Wifi is not a factor but it’s still slow.

I restarted SMART CONNECT as too many household devices were broken with the change. Given that I am testing on an ethernet connected Mac, this should not be an issue, right?

Just now a track started loading at 9:13:55 and finally started playing at 9:14:56 (Afirica) and a second track started loading at 9:17:43 and started playing at 9:15:40 (Solea). Both files are Qobuz files but a full minute between tracks is intolerable. Times in Central time zone.

Oddly, it seems like ARC is now working. . .

8

That screenshot of the Web UI shows an error in the IP address for the gateway. And is there some reason why you are using a static address on the ROCK/NUC rather than an IP reservation for it in your router?

9

Reason for the static IP is that I was trying to resolve the issue with a different DNS Server. I must have mucked up the gateway IP at that time. Nice catch, brother!

Since this didn’t resolve anything, I’m moving it back to Dynamic, which corrected the bad Gateway IP.

10

You could try setting your router to use the different DNS?

11

I had some other problems some months back and set the router to use Cloudflare for DNS with 8.8.8.8 as a secondary. The DNS server change in the screen shot was a hail mary when I though that maybe it was remote files/Qobuz only, but that is not the case. I appreciate the help, @Geoff_Coupe !

I think your observation about the wrong gateway DNS fixed my Roon ARC problems! It seems to work fine over cell networks now. Cheers!

POSSIBLE SOLUTION FOR MAIN PROBLEM
On a whim, I tried connecting a different storage HD to my ROCK. At the moment, everything seems to be working just fine. I ran diagnostics on the old HD and it required repair. In fact, it would not mount at all at first. This strongly suggests that a faulty HD may be the root cause of the original slowness problem. @benjamin , is that a plausible cause? Could a corrupt/damaged HD cause a system wide slowdown?

1 Like
12

Hey @Lanny_Hoff,

Nice work here, and thank you for your sharp eyes @Geoff_Coupe!

Absolutely - keep us posted on how things continue to perform over the next few days. :+1:

13

Doing a bit of stress testing now and it’s working absolutely beautifully. Better than it has for literally years! I have five separate streams over 6 endpoints running simultaneously and it’s all going off without a hitch.

Roon ARC seems to be working fine also.

I’ll update within the 7 day window on how thing are going, but I think it’s great at the moment.

14

Massive delays this morning.

If you check the log, between 9:52-9:56 this morning (central time), there was a massive and ongoing delay. The time bar is scanning back and forth as if it will eventually load. The track in question is God Bless The Child from Lady Sings The Blues, if that matters.

Everything was work OK until then, not as great as yesterday. I have changed nothing in the system.

15

Hello @Lanny_Hoff,

Thank you for your patience while we reviewed the diagnostic data around your provided timestamp. The good news is that we can confidently rule out your local network and internet connection as the cause of this behavior.

Instead, the logs show the following pattern:

03/20 14:57:36 [Local 03/20 09:57:36] Debug: FTMSI-B got length for qo/A38F4C57; 66.4 MBytes
03/20 14:57:36 [Local 03/20 09:57:36] Debug: FTMSI-B-OE set min bandwidth for qo/A38F4C57 to 2755 kbps
03/20 14:57:36 [Local 03/20 09:57:36] Info: FTMSI-B-OE qo/A38F4C57 rid:1162 response took 138ms
03/20 14:57:36 [Local 03/20 09:57:36] Debug: FTMSI-B-OE qo/A38F4C57 rid:1162 request ended -- first block: 0 blocks read: 0 download speed: -256kbps response time: 138ms
03/20 14:57:36 [Local 03/20 09:57:36] Debug: FTMSI-B-OE qo/A38F4C57 interrupted req 1162; missing block 0
03/20 14:57:36 [Local 03/20 09:57:36] Debug: FTMSI-B-OE qo/A38F4C57 created new req 1163 for block 0 p 0; active requests 1`

What is happening here is a specific communication nuance with the Qobuz Content Delivery Network (CDN). A connection is successfully established with their servers, but the data stream is interrupted by an external factor—the CDN responds with a successful connection status but delivers an empty payload (blocks read: 0). Because the expected data is missing, the system continually attempts to re-request the audio blocks.

Our engineering team is actively investigating this specific interaction with the Qobuz CDN to optimize how these streams are negotiated and sustained.

I have attached your case and diagnostic data directly to the active R&D investigation ticket. Please keep an eye on our Roon Software Discussion > Software Release Notes category, as any improvements regarding this streaming behavior will be announced there in future updates.

Let me know if you have any questions in the meantime!

16

It is very helpful to know that my local network and internet connection are not implicated. I look forward to this being solved on the back end. Thank you!

17

Hey @Lanny_Hoff,

We don’t yet have a fix, but I wanted to let you know we do have a tracking thread around this Qobuz issue, where we’ll be posting any and all updates:

If you head to the bottom of that thread, and set the notification setting to ‘watching’ you’ll be notified each time there is a new reply to the thread.

We’ll also share the update once it’s released to Production, via our Software Release notes, which can be found here:

Thanks again for your long-standing patience! :folded_hands:

18

Something does not add up. I am trying to play an album right now (19:04:55 Central) that is a local file and the same exact thing is happening. Very long load time, scanning progress bar, the works. This is not a Qobuz file. @benjamin

19

Hi @Lanny_Hoff,

Apologies if this has already been glazed over, but if you fully disable Qobuz from your account, do you still run into the same lag?

We’re unfortunately unable to look back to the previous timestamp you’ve shared above in the latest diagnostic report from your Roon Server. Feel free to share another local example and we’ll attempt to analyze further.

Thank you

20

Hi @Lanny_Hoff,

Just circling back on this. Were you able to fully disable Qobuz on your account and check whether the lag still shows up? If you have another local example, please send that over as well, since we couldn’t pull the earlier timestamp from the latest Roon Server diagnostic report.