What app are you having the slowness issue with?
· Roon
What kind of performance/speed issue are you experiencing?
· The app is using a lot of resources (CPU/RAM)
Please try to reboot your Roon Server
· Yes, rebooting helps, but the issue returns after some time
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 don't know how to do this
What is the operating system of your Roon Server host machine?
· Linux Server (Ubuntu, Fedora, ArchLinux...)
## Symptoms
·
Playback intermittently stops working. Tracks may finish without advancing to the next track, and pressing Play can result in a delay of more than 10 seconds or no playback at all. The playback status can remain stuck at `LOADING @ 0:00`.
Roon has logged playback information requests that failed to respond within 60 seconds. Restarting the Docker container has sometimes restored playback temporarily, but the problem subsequently returned. On other occasions, restarting did not immediately resolve it.
The issue occurs with locally stored FLAC files and is not limited to a single track.
## Server configuration
·
- Roon Server: 2.74 (Build 1712, Production)
- Host OS: Ubuntu Server
- Deployment: Docker using `ghcr.io/roonlabs/roonserver:latest`
- Networking: Host network
- Container memory limit: 4 GiB
- Host RAM: approximately 11 GiB
- Music library: local ext4 filesystem mounted at `/Music`
- Primary remote: Windows 11 PC
- Audio output: FiiO K11 DAC using WASAPI Exclusive
- Additional remote: MacBook Pro running Roon for macOS
## 1. Persistent CPU consumption by Broker:Media
·
During playback failures, the container has consumed approximately 100% CPU, while memory usage remained well below its 4 GiB limit.
Process and thread inspection identified a thread named `Broker:Media` inside `RoonAppliance` consuming approximately 99.9% CPU continuously.
Two measurements taken approximately two seconds apart showed its CPU time increasing from 21:59.98 to 22:01.99, indicating sustained CPU consumption rather than a brief spike.
The other observed Broker threads were largely idle during these measurements.
## 2. Repeated .NET stack traces involving Query._Cancel()
·
I captured managed thread stacks from the running `RoonAppliance` process using `dotnet-stack`.
During the incident, the following stack appeared:
```text
Roon.Broker.Core!Roon.Broker.Query`3[System.__Canon,System.__Canon,System.__Canon]._Cancel()
RoonBase!Sooloos.SynchronizationContextThread._Dispatch(...)
RoonBase!Sooloos.SynchronizationContextThread._Go()
System.Private.CoreLib!System.Threading.Thread.StartCallback()
```
The same stack was observed again in a later capture while the issue persisted.
I have not conclusively established that this managed thread is the same thread as the high-CPU Linux thread, but I believe the repeated stack is potentially relevant to the investigation.
## 3. Extremely high radio query activity
·
Roon Server logs contain repeated messages:
```text
Trace: [radio/query] performing channel query
Trace: [radio/query] query returned 0 Roon.Broker.Api.Channel(s)
```
By counting these messages per timestamped second, I observed bursts exceeding 10,000 logged query operations per second. For example, approximately 10,743 occurrences were recorded at 05:16:57 on October 25, 2026.
The queries repeatedly returned zero channels. I do not know whether this is expected under any internal condition, but the volume appears unusual.
## 4. Playback request timeouts
·
During the failure, Roon logged messages such as:
```text
Warn: [zone FiiO K11] [zone] playback info request 34 did not answer in 60s
```
The zone subsequently remained at `LOADING @ 0:00`.
This suggests that playback-related requests are not being processed or answered in a timely manner.
## 5. MacBook remote reconnection investigation
·
I compared macOS power-management logs with Roon Server connection and query logs.
Several radio query bursts occurred shortly after the MacBook experienced a DarkWake event and its Roon remote reconnected to the server. In one instance, Roon reported that a new session was initialized because the previous session could not be resumed.
However, I have not established that the MacBook or macOS DarkWake is the root cause.
I completely quit Roon on the MacBook and verified that no matching Roon or RAATServer processes remained. Despite this, the server continued showing high CPU usage and playback failures.
During a later test, I reopened the MacBook remote and attempted playback while monitoring the server logs. Playback failed again, although no new radio query storm was captured during that particular observation window.
These results suggest that the issue can persist independently of an active MacBook Roon process.
## 6. Other troubleshooting
·
- Restarted the Docker container multiple times, with only temporary or inconsistent improvement.
- Disabled the Home Assistant Roon integration; the problem still recurred.
- Changed the audio analysis settings to Throttled; the problem persisted.
- Confirmed that the library is stored on a local filesystem rather than a network share.
- Inspected Docker resource usage, individual Linux threads, managed .NET stacks, and Roon Server logs.
I have not yet tested rebooting the networking equipment or changing router DNS settings, so those tests should not be considered completed.
## Request for engineering investigation
·
My leading hypothesis is that Roon Broker enters an abnormal high-CPU state involving its media thread and possibly query cancellation or synchronization work.
The repeated `Query._Cancel()` stack, excessive radio query activity, playback request timeouts, and persistent `Broker:Media` CPU consumption may be related, but I cannot confirm a single root cause from the available evidence.
Could the engineering team investigate whether Roon Server 2.74 Build 1712 has a known issue involving Broker media-thread CPU consumption, query cancellation, radio query scheduling, or remote reconnection handling?
I would also appreciate guidance on any targeted diagnostic method that could correlate the high-CPU Linux thread with its managed .NET stack.
I am looking for a permanent resolution rather than relying on repeated Docker container restarts.
Thank you.
Timestamp of issue occurrences
· The issue occurred repeatedly on October 25, 2026 (UAE local time, UTC+4). Observed incidents include: - 03:57:38 — MacBook Roon remote reconnected, followed by a burst of radio queries. - 04:15:38 — Remote reconnection followed by another burst of radio queries. - 04:37:50 — Remote reconnection followed by another burst of radio queries. - 05:16:52–05:16:59 — A particularly large radio query burst, exceeding 10,000 logged query operations per second. - Approximately 05:52–05:53 — Playback information requests timed out after 60 seconds, and tracks remained stuck at LOADING @ 0:00. The issue is intermittent and has occurred repeatedly rather than at one specific time.
Describe the issue
## Persistent Roon Server playback failures and abnormal CPU usage in Roon Broker
I am experiencing recurring playback failures on my Roon Server, running Roon Server 2.74 (Build 1712, Production) on Ubuntu Server inside Docker. The issue started in October 2026, after a long period of normal operation.
Describe your network setup
My home network uses Ubiquiti UniFi networking equipment, with an internet connection rated at approximately 700 Mbps and a 1 Gbps Ethernet switch.
The Roon Server runs on Ubuntu Server inside Docker and is connected to my home network. My primary Roon client is a Windows 11 PC, which uses a FiiO K11 DAC for audio playback. I also use a MacBook Pro as an additional Roon remote.
The server, Windows PC, and MacBook are on my home network. I have not yet tested whether rebooting the networking equipment or changing the router's DNS settings affects this issue.
I have not confirmed the exact router model or ISP-specific details in this report.