Intermittent Slow-Loading in Roon Desktop and Roon Community (ref#KVLYG1)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· The app takes a long time to respond to commands

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?

· Nucleus

Which model Nucleus do you have?

· Nucleus Rev B

Timestamp of issue occurrences

· September 20, 2026 at approximately 12:48:46 PM PDT: Roon Community slow request with server x-runtime 7.944977 seconds. x-request-id: bc513c56-7a38-40b2-add6-123fc045dcd7 September 20, 2026 at approximately 5:44:48 PM PDT: Roon Community slow request with TTFB 7.159467 seconds and server x-runtime 6.818689 seconds. x-request-id: a0bc51e1-9d52-42b9-b227-b08ca5275c5f The Roon desktop application has also exhibited the intermittent slow/fast-loading behavior during this same period, although I did not record an exact desktop-app timestamp for those occurrences.

Describe the issue

I am experiencing intermittent slow-loading behavior in the Roon desktop application. At times pages/content respond normally, but at other times there is a several-second delay before content begins loading. The behavior can then return to normal without any change on my end.

I have also observed essentially the same slow/fast behavior on the Roon Community website, so I investigated that separately to determine whether the problem was local network latency.

I have reproduced the Community slowdown across multiple browsers and operating systems, including Firefox, Edge and Safari on Linux, Windows and macOS. I have also reproduced it while bypassing my normal eero network and using an iPhone hotspot, so it does not appear specific to my LAN, router or DNS configuration.

Curl testing against community.roonlabs.com shows that DNS resolution, TCP connection and TLS negotiation complete normally. During a slow event, however, time-to-first-byte increases to approximately 6–8 seconds.

More importantly, the HTTP response headers show that most of this delay is occurring inside the Discourse application itself.

One slow request produced:

TTFB: approximately 8 seconds
x-runtime: 7.944977
x-discourse-cached: skip
x-request-id: bc513c56-7a38-40b2-add6-123fc045dcd7

A fast request shortly afterward produced:

x-runtime: 0.550203
x-discourse-cached: store
x-request-id: 0ec8d9d8-7338-4902-bc35-75d0b9ac372b

A second independently captured slow event produced:

TTFB: 7.159467 seconds
x-runtime: 6.818689
x-discourse-cached: skip
x-request-id: a0bc51e1-9d52-42b9-b227-b08ca5275c5f

In that second example, about 6.82 seconds of the 7.16-second request was reported by the server itself as application runtime.

The Roon desktop application exhibits a very similar intermittent slow-loading/fast-loading pattern. I am not claiming that the Roon application and Community delays necessarily have the same root cause, but the similarity is significant enough that I wanted Support to investigate whether there could be a shared Roon cloud/backend component involved.

Restarting the Roon Server does not resolve the behavior.

Could you please investigate the Roon-side services and, if possible, trace the above Community x-request-id values in the server logs? I can provide additional Roon logs and exact timestamps of desktop-app slow events if needed.

Describe your network setup

ISP: Xfinity

Router / Wi-Fi system: eero Pro 6E mesh network.

My primary Roon-related computers are connected by wired Ethernet through Netgear Ethernet switches on the eero network.

The intermittent slow-loading behavior is not limited to the home network. I have also reproduced the same Community website behavior while completely bypassing the Xfinity/eero LAN and connecting through an iPhone cellular hotspot.

This is therefore reproducible across two independent Internet connections and is not specific to the eero network.

2

Hello @Wakajazz

Two separate things here, and it is worth keeping them apart.

The Community website. Your analysis is sound and the headers say what you read them as saying. It is also a different system from Roon. The forum runs on Discourse, and x-runtime, x-discourse-cached and those x-request-id values belong to the forum’s own logs rather than to anything in Roon Server or Roon’s cloud services. We cannot trace those request IDs in our logs, so please do not read anything into it either way. We will pass your measurements to the people who run the forum.

The Roon desktop app. This one is real; it is visible in your Nucleus diagnostics, and your instinct to rule out the network was right.

Across 37 days of logs, the server never restarted, so nothing is crashing. What we see instead is the server periodically stopping to collect memory, for long enough to be felt. The median pause is about a third of a second, one in ten exceeds two thirds of a second, and the longest reach fourteen seconds. The server answers nothing during a pause, which is what produces a several-second wait followed by everything behaving normally again.

Your measurements are a useful addition to work already have open ticket with our development team on this, and we have added them.

3

Thanks, @Vadim. This is extremely helpful and explains the behavior I have been seeing in the Roon desktop application very well.

I will keep the Community website issue separate as you suggest.

For the Nucleus issue, since you can see the memory-collection pauses in the diagnostics and this is already associated with an open development ticket, I will leave my configuration unchanged.

Please let me know if there are any additional timestamps, diagnostics, or testing that would be useful to the team.

Thanks again.

4

Hi @Wakajazz,

For context, our development team has a bundle of tickets pushing through the pipeline to improve overall background indexing. Libraries on the upper end of the bell curve in terms of metadata complexity tend to be affected.

Here’s what we can do:

  1. we’ll gather diagnostic logging remotely to build a more reliable sample size of logging

  2. we’ll share any patterns or observations that might help remedy some of the memory pressure or high garbage collection stats in the meantime

  3. eventually, we’ll invite you to the Early Access program to test a fix (although you can join anytime you want, it’s public).

Thanks for your understanding.