Crashes on Roon Rock NUC8i7beh while playing Hi-Res Qobuz tracks (ref#N527PQ)

Martin_Reher · May 9, 2026, 9:44am

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

· 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 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

· 05/09 10:29:51 am

Describe the issue

System: Roon Rock NUC8i7beh with 16GB RAM -> Crashes occur when playing Qubuz tracks at 192/24 on the Linn Akurate DS1
After restarting the Roon Rock, no crashes are observed.
The crashes occur after approximately 24–48 hours -> Is the RAM running out of space?
No network problem

Log with error message:

05/09 08:29:46 [Local 05/09 10:29:46] Warn: FTMSI-B-OE qo/E752B571: poor connection kbps:4539.0 (min:6313.0)
05/09 08:29:46 [Local 05/09 10:29:46] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:46 [Local 05/09 10:29:46] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [1% buf] [PLAYING @ 0:41/4:55] Africa (Album Version) - Toto
05/09 08:29:46 [Local 05/09 10:29:46] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:46 [Local 05/09 10:29:46] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:47 [Local 05/09 10:29:47] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:47 [Local 05/09 10:29:47] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:47 [Local 05/09 10:29:47] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:48 [Local 05/09 10:29:48] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:48 [Local 05/09 10:29:48] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:48 [Local 05/09 10:29:48] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:48 [Local 05/09 10:29:48] Trace: [library] endmutation in 116ms
05/09 08:29:49 [Local 05/09 10:29:49] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:49 [Local 05/09 10:29:49] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:49 [Local 05/09 10:29:49] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:49 [Local 05/09 10:29:49] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:50 [Local 05/09 10:29:50] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:50 [Local 05/09 10:29:50] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:50 [Local 05/09 10:29:50] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:50 [Local 05/09 10:29:50] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:51 [Local 05/09 10:29:51] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:51 [Local 05/09 10:29:51] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:51 [Local 05/09 10:29:51] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:51 [Local 05/09 10:29:51] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [1% buf] [PLAYING @ 0:41/4:55] Africa (Album Version) - Toto
05/09 08:29:52 [Local 05/09 10:29:52] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:52 [Local 05/09 10:29:52] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:52 [Local 05/09 10:29:52] Debug: [prebuffer] sleeping in read -- this isn't good
05/09 08:29:52 [Local 05/09 10:29:52] Info: [stats] 39894mb Virtual, 4053mb Physical, 1107mb Managed, 2946mb estimated Unmanaged, 452 Handles, 106 Threads, 4.35% of runtime in GC pauses, 87ms last GC pause duration

After restarting the Roon server -> OK:
Elements:
Source Format=Flac 192000/24/2 Quality=Lossless
Output OutputType=SongcastDirect Quality=Lossless SubType= Model=Linn Akurate DS
------------------------------------------------------------
05/09 08:31:14 [Local 05/09 10:31:14] Trace: [prebuffer] ready 652800/1920000 (34%) @ 0/295 sec
05/09 08:31:14 [Local 05/09 10:31:14] Debug: [easyhttp] [1426] POST to https://api.roonlabs.net/device-map/1/register returned after 169 ms, status code: 200, request body size: 6 KB
05/09 08:31:14 [Local 05/09 10:31:14] Trace: [devicemap] device map updated
05/09 08:31:17 [Local 05/09 10:31:17] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 1, Got 2
05/09 08:31:18 [Local 05/09 10:31:18] Info: [stats] 39585mb Virtual, 1382mb Physical, 475mb Managed, 907mb estimated Unmanaged, 411 Handles, 93 Threads, 9.14% of runtime in GC pauses, 2ms last GC pause duration
05/09 08:31:18 [Local 05/09 10:31:18] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [77% buf] [PLAYING @ 0:03/4:55] Africa (Album Version) - Toto
05/09 08:31:23 [Local 05/09 10:31:23] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:08/4:55] Africa (Album Version) - Toto
05/09 08:31:27 [Local 05/09 10:31:27] Debug: [easyhttp] [1414] POST to https://api.roonlabs.net/browse/1/works/trackCounts?c=qobuz-de&tidal=max returned after 18084 ms, status code: 503
05/09 08:31:28 [Local 05/09 10:31:28] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:13/4:55] Africa (Album Version) - Toto
05/09 08:31:31 [Local 05/09 10:31:31] Debug: [easyhttp] [1427] POST to https://api.roonlabs.net/discovery/1/query returned after 182 ms, status code: 200, request body size: 74 B
05/09 08:31:33 [Local 05/09 10:31:33] Info: [stats] 39497mb Virtual, 1390mb Physical, 482mb Managed, 908mb estimated Unmanaged, 414 Handles, 77 Threads, 8.69% of runtime in GC pauses, 8ms last GC pause duration
05/09 08:31:34 [Local 05/09 10:31:34] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:18/4:55] Africa (Album Version) - Toto
05/09 08:31:39 [Local 05/09 10:31:39] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:24/4:55] Africa (Album Version) - Toto
05/09 08:31:44 [Local 05/09 10:31:44] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:29/4:55] Africa (Album Version) - Toto
05/09 08:31:48 [Local 05/09 10:31:48] Info: [stats] 39457mb Virtual, 1396mb Physical, 488mb Managed, 908mb estimated Unmanaged, 414 Handles, 72 Threads, 8.37% of runtime in GC pauses, 7ms last GC pause duration
05/09 08:31:49 [Local 05/09 10:31:49] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:34/4:55] Africa (Album Version) - Toto
05/09 08:31:54 [Local 05/09 10:31:54] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:39/4:55] Africa (Album Version) - Toto
05/09 08:31:59 [Local 05/09 10:31:59] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:44/4:55] Africa (Album Version) - Toto
05/09 08:32:03 [Local 05/09 10:32:03] Info: [stats] 39449mb Virtual, 1402mb Physical, 494mb Managed, 908mb estimated Unmanaged, 413 Handles, 73 Threads, 8.17% of runtime in GC pauses, 8ms last GC pause duration
05/09 08:32:04 [Local 05/09 10:32:04] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:49/4:55] Africa (Album Version) - Toto
05/09 08:32:09 [Local 05/09 10:32:09] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:54/4:55] Africa (Album Version) - Toto

----------
AI Feedback:
3. Confront Roon Support with these figures: Copy these two exact log excerpts (before: 3900 MB RAM / after: 1300 MB RAM) and post them on the Roon forum. This clearly demonstrates a memory leak in the songcastdirect module.

Describe your network setup

Internet provider: Deutsche Glasfaser -> 200 Mbps upload /download
Router: Fritzbox
Switch: TP-Link SG3210 -> Linn and Nuc both connected to it.
No IGMP snooping, no QoS, no flow control.
LAN cables (all): 1.5 m Audioquest Cinamon

vadim · May 11, 2026, 1:03pm

Hello @Martin_Reher,

Thank you for reaching out and for providing such detailed logs.

Let’s dive straight into the logs and address the AI feedback you received regarding the memory usage.

The “Memory Leak” Theory

First, to address the AI feedback you received: you and the AI tool actually spotted something valid. There is indeed a memory leak present in the system. Our R&D team is aware of this behavior and is currently working on a fix for it. You can look closeley at our Roon Software Discussion > Software Release Notes for further updates regarding this matter.

However, looking closely at your logs, this memory leak is not what is causing your playback to crash.

The true reason the stream is dropping is found in these specific lines right before the crash:

Warn: FTMSI-B-OE qo/E752B571: poor connection kbps:4539.0 (min:6313.0)
Debug: [prebuffer] sleeping in read -- this isn't good
[1% buf]

What this means under the hood: Roon uses a system called FTMSI-B to fetch streaming tracks from Qobuz in small data blocks. This system dynamically calculates exactly how much bandwidth is required to keep the music playing smoothly.

Streaming 24/192 FLAC requires a massive, sustained data pipeline. The log explicitly shows that your NUC requires a minimum of 6313 kbps to download this track fast enough, but your connection to Qobuz’s servers dropped to 4539 kbps. Because the download speed fell below the minimum requirement, Roon’s audio buffer emptied out completely ([1% buf]), the playback decoder “went to sleep” waiting for data (sleeping in read), and the stream collapsed.

Rebooting the ROCK forces a fresh network handshake with Qobuz, which temporarily connects you to a faster server node and clears the bottleneck for a day or two.

Even with a 200 Mbps fiber connection, the specific routing from Qobuz’s Content Delivery Network (CDN) to your NUC can occasionally get bogged down. To fix this:

DNS Settings: Please double-check that your Fritzbox router’s DNS is explicitly set to Cloudflare (1.1.1.1) or Google (8.8.8.8). This is the single most effective way to ensure your network finds the fastest, most reliable Qobuz servers.
Lower the Streaming Quality: As a temporary diagnostic test, try lowering your Qobuz streaming quality in Roon to 24/96 or CD Quality (16/44.1). By lowering the file size, you lower the “minimum bandwidth” requirement. If the crashes stop entirely, it confirms your local network routing occasionally struggles to sustain the 6.3 Mbps minimum required for 24/192 files.
Bypass the Switch: Just to be absolutely sure your local hardware isn’t throttling the incoming internet traffic to the server over time, try bypassing the TP-Link switch and plugging the NUC directly into the Fritzbox.

Let us know if changing the DNS or temporarily lowering the streaming quality stabilizes your system!

Martin_Reher · May 11, 2026, 2:27pm

DNS Settings:
I had already set Cloudflare (1.1.1.1) on the Fritzbox.
I have now entered the IP address statically on Roon Rock again, since the IP for DNS has also been changed to 1.1.1.1.
Lower Streaming Quality:
The issues only occurred with the 24/192 quality (dropouts). During that time, I was able to stream 24/96 tracks without any dropouts.
Bypass the Switch:
I’ve already tested this as well → same result → interruptions after about 24–48 hours there too.

Addendum:
During the time when I was experiencing dropouts while streaming via Roon Rock to Qobuz, I streamed the same 24/192 song via the Linn app (UPnP) (without Roon) – without any dropouts

Martin_Reher · May 13, 2026, 7:57am

Additional observation:
The issue (disconnections after approximately 24–48 hours) occurs not only when streaming from Qobuz, but also when streaming local songs from the SSD in the NUC.
Rebooting the Roon Server resolves the issue.

vadim · May 13, 2026, 12:36pm

Hello @Martin_Reher,

Thank you for providing that crucial update. The fact that this issue also occurs with local files playing directly from the internal SSD completely changes our troubleshooting direction. We can safely take Qobuz routing and internet bandwidth out of the equation.

The Hardware Factor

While our R&D team is actively working on patching the memory leak we discussed earlier, I am highly doubtful that the memory leak is the actual cause of your local files dropping out. Typically, a memory leak of that severity will cause the entire Roon Server process to crash or freeze the web interface completely, rather than just choking the audio buffer while the system remains otherwise responsive.

Because you are running a NUC8 and the degradation happens consistently after 24–48 hours of uptime, this may points to a hardware-level issue.

I highly recommend checking the following:

Thermal Throttling (Overheating): NUC chassis are very compact and notoriously prone to dust buildup. If the CPU or the M.2 SSD gets too hot after running continuously for a day or two, the motherboard will aggressively throttle their speeds to prevent physical damage. This sudden drop in read speed perfectly explains the [prebuffer] sleeping in read errors you are seeing in the logs. Please check the cooling fan, blow out any dust from the vents, and consider cleaning and reapplying fresh thermal paste to the CPU.
RAM Integrity: Memory modules can develop faults that only trigger once the system has been running for a while and data is written to specific addresses. I recommend creating a bootable USB drive with Memtest86 and letting it run a few passes on your NUC to ensure the RAM is 100% healthy.
SSD Health: Intermittent read timeouts can also be an early warning sign of a failing storage drive.

If you perform these hardware and thermal checks and everything comes back perfectly healthy, then we must assume your system is hitting a rare edge-case interaction with the known memory leak.

If that turns out to be the case, the only path forward is to wait for the R&D team to release the upcoming memory patch. In the meantime, as frustrating as it is, manually rebooting the ROCK once a day remains your best workaround to keep the memory cleared and the music playing.

Martin_Reher · May 14, 2026, 8:41am

Current status:
RAM upgraded from 16GB to 32GB. Akasar Turing instead of a fan.
RAM test with 32GB:
1st run: approx. 2 hours, no errors
2nd run ended at approx. 4 hours and 83%—everything error-free up to that point. RAM is fine for me.
I was surprised that the 2nd run took so long. AI tells me that this is normal, though, because the 2nd run performs more detailed testing.
At that point (i.e., after 6 hours of RAM testing), the Akasa is already quite warm. In the BIOS, the CPU temperature was 53 degrees Celsius, memory temp 60 degrees Celsius, and motherboard 57 degrees Celsius. That’s okay for me.
The operating system is on an M.2 SSD (250GB) (no extra heatsink), and the library is on an internal 1TB SATA SSD.
I’ll keep an eye on this with the hardware changes.

benjamin · May 15, 2026, 6:28pm

Sounds good @Martin_Reher, we’ll be monitoring for your reply and results

Martin_Reher · May 17, 2026, 7:22am

Further tests:

Tidal account also activated.

After a while:

Disconnections again, starting with Tidal, then with Qobuz—and a little later, disconnections also occurred with songs on the NUC’s local

SSD

Using the app (viewing playlists, etc.) and starting new tracks became sluggish. It seems as though Roon Rock is getting slower and slower.

Linn Akurate DS1, TP-Link SG3210 switch, and Fritzbox 7590AX rebooted.

No change. It took longer for Roon to log back into Tidal and Qobuz (approx. 3 min).

Approx. two hours without music playback → NUC case (Akasa) cool.

During the first playback of 24/192 songs via Tidal/Qobuz, dropouts occurred immediately → so no heat issue

It seems as though Roon is getting slower and slower

Playing from local SSD:

------------

Elements:

Source Format=Flac 192000/24/2 BitRate=5285 Quality=Lossless

Output OutputType=SongcastDirect Quality=Lossless SubType= Model=Linn Akurate DS

------------------------------------------------------------

05/17 05:35:32 [Local 05/17 07:35:32] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 64, Got 65

05/17 05:35:33 [Local 05/17 07:35:33] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:05/9:06] Amused to Death - Roger Waters / Jeff Beck

05/17 05:35:36 [Local 05/17 07:35:36] Info: [stats] 72430mb Virtual, 4057mb Physical, 1286mb Managed, 2771mb estimated Unmanaged, 426 Handles, 109 Threads, 11.65% of runtime in GC pauses, 141ms last GC pause duration

05/17 05:35:38 [Local 05/17 07:35:38] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:09/9:06] Amused to Death - Roger Waters / Jeff Beck

05/17 05:35:42 [Local 05/17 07:35:42] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 70, Got 72

05/17 05:35:42 [Local 05/17 07:35:42] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 71, Got 72

05/17 05:35:43 [Local 05/17 07:35:43] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:13/9:06] Amused to Death - Roger Waters / Jeff Beck

05/17 05:35:48 [Local 05/17 07:35:48] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:17/9:06] Amused to Death - Roger Waters / Jeff Beck

05/17 05:35:51 [Local 05/17 07:35:51] Info: [stats] 72478mb Virtual, 4047mb Physical, 1267mb Managed, 2780mb estimated Unmanaged, 432 Handles, 116 Threads, 11.66% of runtime in GC pauses, 141ms last GC pause duration

05/17 05:35:52 [Local 05/17 07:35:52] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 78, Got 79

05/17 05:35:53 [Local 05/17 07:35:53] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:20/9:06] Amused to Death - Roger Waters / Jeff Beck

05/17 05:35:59 [Local 05/17 07:35:59] Trace: [HighEnd] [Lossless, 24/192 FLAC => 24/192] [100% buf] [PLAYING @ 1:23/9:06] Amused to Death - Roger Waters / Jeff Beck

Playin from Qobuz:

Source Format=Flac 192000/24/2  Quality=Lossless

Output OutputType=SongcastDirect Quality=Lossless SubType= Model=Linn Akurate DS

------------------------------------------------------------

05/17 05:39:57 [Local 05/17 07:39:57] Trace: [prebuffer] ready 652800/1920000 (34%) @ 0/295 sec

05/17 05:40:00 [Local 05/17 07:40:00] Trace: [HighEnd] [Lossless 9.5x, 24/192 QOBUZ FLAC => 24/192] [33% buf] [PLAYING @ 0:00] Africa (Album Version) - Toto

05/17 05:40:05 [Local 05/17 07:40:05] Trace: [HighEnd] [Lossless 36.7x, 24/192 QOBUZ FLAC => 24/192] [38% buf] [PLAYING @ 0:04/4:55] Africa (Album Version) - Toto

05/17 05:40:05 [Local 05/17 07:40:05] Warn: FTMSI-B-OE qo/63D45446: poor connection kbps:4350.0 (min:6313.0)

05/17 05:40:09 [Local 05/17 07:40:09] Info: [stats] 72542mb Virtual, 4080mb Physical, 1347mb Managed, 2733mb estimated Unmanaged, 434 Handles, 120 Threads, 11.78% of runtime in GC pauses, 137ms last GC pause duration

05/17 05:40:10 [Local 05/17 07:40:10] Trace: [HighEnd] [Lossless 58.6x, 24/192 QOBUZ FLAC => 24/192] [40% buf] [PLAYING @ 0:04/4:55] Africa (Album Version) - Toto

05/17 05:40:10 [Local 05/17 07:40:10] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 5, Got 7

05/17 05:40:10 [Local 05/17 07:40:10] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 6, Got 7

05/17 05:40:15 [Local 05/17 07:40:15] Trace: [HighEnd] [Lossless 81.2x, 24/192 QOBUZ FLAC => 24/192] [39% buf] [PLAYING @ 0:11/4:55] Africa (Album Version) - Toto

05/17 05:40:15 [Local 05/17 07:40:15] Warn: FTMSI-B-OE qo/63D45446: poor connection kbps:3958.0 (min:6313.0)

05/17 05:40:20 [Local 05/17 07:40:20] Trace: [HighEnd] [Lossless 98.9x, 24/192 QOBUZ FLAC => 24/192] [39% buf] [PLAYING @ 0:11/4:55] Africa (Album Version) - Toto

05/17 05:40:20 [Local 05/17 07:40:20] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 12, Got 14

05/17 05:40:20 [Local 05/17 07:40:20] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 13, Got 14

05/17 05:40:24 [Local 05/17 07:40:24] Info: [stats] 72518mb Virtual, 4080mb Physical, 1346mb Managed, 2734mb estimated Unmanaged, 434 Handles, 117 Threads, 11.78% of runtime in GC pauses, 142ms last GC pause duration

05/17 05:40:25 [Local 05/17 07:40:25] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [37% buf] [PLAYING @ 0:18/4:55] Africa (Album Version) - Toto

05/17 05:40:25 [Local 05/17 07:40:25] Warn: FTMSI-B-OE qo/63D45446: poor connection kbps:3821.0 (min:6313.0)

05/17 05:40:30 [Local 05/17 07:40:30] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [36% buf] [PLAYING @ 0:19/4:55] Africa (Album Version) - Toto

05/17 05:40:30 [Local 05/17 07:40:30] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 20, Got 21

05/17 05:40:35 [Local 05/17 07:40:35] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [37% buf] [PLAYING @ 0:25/4:55] Africa (Album Version) - Toto

05/17 05:40:35 [Local 05/17 07:40:35] Warn: FTMSI-B-OE qo/63D45446: poor connection kbps:3754.0 (min:6313.0)

05/17 05:40:39 [Local 05/17 07:40:39] Info: [stats] 72518mb Virtual, 4080mb Physical, 1347mb Managed, 2733mb estimated Unmanaged, 428 Handles, 118 Threads, 11.79% of runtime in GC pauses, 139ms last GC pause duration

05/17 05:40:40 [Local 05/17 07:40:40] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 26, Got 28

05/17 05:40:40 [Local 05/17 07:40:40] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 27, Got 28

05/17 05:40:40 [Local 05/17 07:40:40] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [37% buf] [PLAYING @ 0:26/4:55] Africa (Album Version) - Toto

05/17 05:40:45 [Local 05/17 07:40:45] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [37% buf] [PLAYING @ 0:32/4:55] Africa (Album Version) - Toto

-------------------

Immediately afterward, stopped the Roon server and then restarted it → No more dropouts detected!!!

SignalPath Quality = Lossless

Elements:

Source Format=Flac 192000/24/2  Quality=Lossless

Output OutputType=SongcastDirect Quality=Lossless SubType= Model=Linn Akurate DS

------------------------------------------------------------

05/17 05:45:41 [Local 05/17 07:45:41] Trace: [prebuffer] ready 652800/1920000 (34%) @ 0/295 sec

05/17 05:45:46 [Local 05/17 07:45:46] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [90% buf] [PLAYING @ 0:04/4:55] Africa (Album Version) - Toto

05/17 05:45:51 [Local 05/17 07:45:51] Debug: [easyhttp] [1437] POST to https://api.roonlabs.net/discovery/1/query returned after 178 ms, status code: 200, request body size: 74 B

05/17 05:45:51 [Local 05/17 07:45:51] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:09/4:55] Africa (Album Version) - Toto

05/17 05:45:51 [Local 05/17 07:45:51] Info: [stats] 72029mb Virtual, 1604mb Physical, 730mb Managed, 874mb estimated Unmanaged, 411 Handles, 77 Threads, 7.5% of runtime in GC pauses, 8ms last GC pause duration

05/17 05:45:56 [Local 05/17 07:45:56] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:14/4:55] Africa (Album Version) - Toto

05/17 05:46:01 [Local 05/17 07:46:01] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:19/4:55] Africa (Album Version) - Toto

05/17 05:46:06 [Local 05/17 07:46:06] Info: [stats] 71965mb Virtual, 1610mb Physical, 737mb Managed, 873mb estimated Unmanaged, 411 Handles, 69 Threads, 7.4% of runtime in GC pauses, 8ms last GC pause duration

05/17 05:46:07 [Local 05/17 07:46:07] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:24/4:55] Africa (Album Version) - Toto

05/17 05:46:12 [Local 05/17 07:46:12] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:29/4:55] Africa (Album Version) - Toto

05/17 05:46:17 [Local 05/17 07:46:17] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:35/4:55] Africa (Album Version) - Toto

05/17 05:46:21 [Local 05/17 07:46:21] Info: [stats] 71965mb Virtual, 1618mb Physical, 741mb Managed, 877mb estimated Unmanaged, 411 Handles, 71 Threads, 7.35% of runtime in GC pauses, 8ms last GC pause duration

05/17 05:46:22 [Local 05/17 07:46:22] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:40/4:55] Africa (Album Version) - Toto

05/17 05:46:27 [Local 05/17 07:46:27] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:45/4:55] Africa (Album Version) - Toto

05/17 05:46:33 [Local 05/17 07:46:33] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:50/4:55] Africa (Album Version) - Toto

05/17 05:46:36 [Local 05/17 07:46:36] Info: [stats] 71965mb Virtual, 1623mb Physical, 751mb Managed, 872mb estimated Unmanaged, 405 Handles, 73 Threads, 7.27% of runtime in GC pauses, 8ms last GC pause duration

05/17 05:46:38 [Local 05/17 07:46:38] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 0:55/4:55] Africa (Album Version) - Toto

05/17 05:46:43 [Local 05/17 07:46:43] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 1:00/4:55] Africa (Album Version) - Toto

05/17 05:46:48 [Local 05/17 07:46:48] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 1:06/4:55] Africa (Album Version) - Toto

05/17 05:46:51 [Local 05/17 07:46:51] Info: [stats] 71965mb Virtual, 1633mb Physical, 753mb Managed, 880mb estimated Unmanaged, 411 Handles, 73 Threads, 7.23% of runtime in GC pauses, 8ms last GC pause duration

05/17 05:46:53 [Local 05/17 07:46:53] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 1:11/4:55] Africa (Album Version) - Toto

05/17 05:46:58 [Local 05/17 07:46:58] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 1:16/4:55] Africa (Album Version) - Toto

05/17 05:47:04 [Local 05/17 07:47:04] Trace: [HighEnd] [Lossless, 24/192 QOBUZ FLAC => 24/192] [100% buf] [PLAYING @ 1:21/4:55] Africa (Album Version) - Toto

Conclusion:

The longer the Roon server is active, the slower it becomes. After 48 hours, I can no longer play 24/128 songs.

It starts with Tidal/Roon, then a little later with local songs on the SSD as well.

No thermal issue with the NUC. After a long pause, the problem reoccurs immediately.

Relevant entries in the log:

05/17 05:40:40 [Local 05/17 07:40:40] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 26, Got 28

05/17 05:40:40 [Local 05/17 07:40:40] Warn: [songcastdirect] [Linn Akurate DS] time discontinuity. Expected 27, Got 28

and

with dropouts

05/17 05:40:24 [Local 05/17 07:40:24] Info: [stats] 72518mb Virtual, 4080mb Physical, 1346mb Managed, 2734mb estimated Unmanaged, 434 Handles, 117 Threads, 11.78% of runtime in GC pauses, 142ms last GC pause duration

after Stop/Start → Error no longer occurs:

05/17 05:45:51 [Local 05/17 07:45:51] Info: [stats] 72029mb Virtual, 1604mb Physical, 730mb Managed, 874mb estimated Unmanaged, 411 Handles, 77 Threads, 7.5% of runtime in GC pauses, 8ms last GC pause duration

Linn booted → no change

Roon Server restarted → everything is fine again!!!

benjamin · May 20, 2026, 12:14am

Hey @Martin_Reher,

Thanks for the update and additional information! From a fresh diagnostic report, it does appear that your server is suffering from some known memory-related issues that our development team is actively addressing.

The best workaround for now would be a daily reboot of your server, which I realize is less than ideal.

Separate from the memory issue, there are recurring [zone HighEnd] Track Stopped Due to LostEndpoint events, even when memory looks relatively healthy. These are the Linn Akurate DS1 going unreachable over Songcast/the network. This suggests a secondary issue, possibly related to the TP-Link switch or the Songcast implementation specifically.

See if the following help with this at all:

Disable EEE (Energy-Efficient Ethernet) on the TP-Link SG3210 port connected to the Linn. Linn streamers are known to be sensitive to this
Check the Linn's Songcast multicast subscription — the DS1 may be dropping the multicast group unexpectedly
Test with a static IP on the Linn if it's using DHCP

Thanks, Martin!

Martin_Reher · July 14, 2026, 3:39pm

Playback interruptions with 24/192 after ~6h50 uptime – severe GC pauses and prebuffer starvation

Hi Roon Support,

I am still experiencing playback interruptions with 24-bit / 192 kHz content on my ROCK system, despite the memory optimizations mentioned for Roon 2.70.

After restarting ROCK, playback is initially completely stable. However, after approximately 6 hours and 50 minutes of uptime/playback, the interruptions return.

The issue is most noticeable with 24/192 content. Importantly, I have now also reproduced the problem with local files stored on the internal HDD of the ROCK system. With local files the issue seems to occur somewhat later, but playback eventually becomes unstable as well.

This makes a Qobuz/CDN or general internet bandwidth issue unlikely.

System

Roon ROCK on Intel NUC 8i7
Roon Server 2.70 / Build 1671
Linn Akurate DS1 as Roon Ready endpoint via Ethernet
Qobuz and local music files
Wired network

Relevant log observations

Immediately before the 24/192 playback problem, the log reports:

TransportItem:8000 dirty items, rebuild threshold: 2000

followed by query rebuild activity.

The 24/192 Qobuz stream itself initially opens successfully:

24/192 QOBUZ FLAC => 24/192

Open Result Success

The Linn endpoint also connects and playback starts normally.

Shortly afterwards, however, Roon reports extremely high GC pause times:

11141ms GC pause in last window (73.94% of window)

At the same time, the following message starts appearing repeatedly:

prebuffer sleeping in read -- this isn't good

The playback buffer remains at approximately 1–3%.

Further GC warnings follow:

10927ms GC pause in last window (72.77% of window)

11189ms GC pause in last window (74.05% of window)

and again GC activity exceeding 70% of the monitoring window.

Roon also eventually reports:

poor connection kbps: 5203 (min:6234)

However, I suspect this may be a consequence of RoonServer spending more than 70% of the monitoring window in GC pauses, preventing the prebuffer from being serviced quickly enough.

Reproducible pattern

The pattern is now quite consistent:

Restart ROCK
Playback is completely stable for several hours
After approximately 6–7 hours, 24/192 playback becomes unstable
prebuffer sleeping in read -- this isn't good appears repeatedly
GC pauses increase to approximately 10–11 seconds per 15-second monitoring window (over 70%)
Playback interruptions occur
Restarting ROCK immediately restores stable playback

The fact that local HDD playback eventually shows similar instability is particularly interesting and seems to point away from the network or Qobuz as the primary cause.

Could you please investigate whether this may be related to a RoonServer memory/GC issue, TransportItem/query rebuild activity, or another long-running resource issue in Build 1671?

I can provide the complete RoonServer log covering the period before and during the failure.

Thank you.

benjamin · July 14, 2026, 9:19pm

Hi @Martin_Reher,

Thanks for the report! Our development team just released an additional optimization surrounding your described issues over in our Early Access branch, if you’re interested in potentially giving that a try.

Here is more information:

Let me know if this is something you’d like to try. Thanks!

Martin_Reher · July 15, 2026, 10:28am

Hi Roon Team,
I’ve installed the Early Access version 2.71.
I’ll see if that fixes the problem and let you know.

Thank you very much!!

vadim · July 15, 2026, 1:25pm

Hello @Martin_Reher

Thanks for giving 2.71 (build 1674) a try. Please let us know how playback holds up once you’ve had a chance to run it for a full day or more, particularly past that 6 to 7 hour mark where you’d previously seen the GC pauses return.

We’ll keep this thread open and waiting on your update.

Martin_Reher · July 15, 2026, 2:43pm

Hi @benjamin,

Thanks. I tested Early Access Roon 2.71 Build 1674, but unfortunately the issue is still reproducible.

The pattern is essentially the same:

After restarting ROCK, playback is initially stable.
Earlier in the session, RoonServer shows only around 1.2% runtime in GC pauses and approximately 160–170 ms GC pause per monitoring window.
After several hours, 24/192 playback becomes unstable and the playback buffer collapses.

During the failure with Toto – “Africa” (24/192 Qobuz), the log shows:

14517ms GC pause in last window (96.39% of window)

followed by repeated:

prebuffer sleeping in read -- this isn't good

The buffer then remains at approximately 1–2%.

Further GC statistics show:

13446ms GC pause in last window (89.02% of window)

13847ms GC pause in last window (91.95% of window)

13943ms GC pause in last window (92.46% of window)

Roon also reports poor connection, but given that RoonServer is spending up to 96% of the monitoring window in GC pauses at exactly the same time, I suspect the low streaming throughput may be a consequence rather than the primary cause.

Interestingly, unlike my previous Build 1671 log, the current Build 1674 log shows:

modified_items: 0, query_rebuilds: 0

during the failure.

So the previous 8000 dirty TransportItems may not be the actual trigger.

I have attached the complete RoonServer log from Build 1674.

Martin_Reher_B1674_Logs_ref#N527PQ.zip

Unfortunately, Build 1674 has not resolved the issue on my ROCK system. The extreme GC activity and prebuffer starvation are still clearly reproducible.

Please let me know if your development team would like me to perform any additional tests or provide further logs.

Thanks,
Martin

benjamin · July 15, 2026, 7:11pm

Hey @Martin_Reher,

Thank you for testing 2.71 and attaching the log traces, and for the really careful analysis. You’ve read this correctly, so I want to confirm it clearly: this is not a Qobuz, CDN, DNS, or local network problem, and it isn’t thermal or a RAM/SSD fault. It’s a RoonServer memory/GC issue, and the “poor connection” line is a symptom of it rather than the cause.

I’m escalating this to our development team with your logs attached and the timeline above, specifically as an unresolved GC/memory-retention issue over long uptime rather than a network matter. I’ll follow up here as soon as I have something back from them.

In the meantime I know it’s not satisfying, but a daily restart of RoonServer remains the reliable workaround to keep the heap clear. If the team asks for anything further, I may come back to request another log capture, thank you again for being so thorough with these.

Martin_Reher · July 21, 2026, 5:51pm

Hi Benjamin,

Just a quick update.

I installed Early Access 2.71 Build 1675.

There is a significant improvement compared to Build 1674.

The first playback interruption occurred only after approximately 1 day 14 hours of continuous uptime (previously it was around 6 hours 50 minutes on Build 1671).

After rebooting ROCK, the system has now been running for 2 days 5 hours without any playback interruptions so far.

I will continue monitoring and report back if the issue reappears.

This looks like a significant improvement, although I cannot yet say whether the problem has been completely resolved.

benjamin · July 23, 2026, 11:38pm

Thank you for the feedback @Martin_Reher, we’ll share it with development.