· None of the above quite fits
· None of these quite match
· Roon freezing at the end of tracks when streaming to group
· My router is a Ubiquity Dream Router 7 and I have a Netgear GS116NA connected to it which supports my Roon Nucleus and one (of three) RoPieee end points.
Here’s a write up on the issue I pulled together with the help of Claude reviewing the log file:
Summary
Grouped zone playback consistently fails to advance to the next track at transitions when 2 or more RAAT endpoints are grouped. All endpoints drop out simultaneously, Roon kills the stream, and playback halts — requiring a manual Next press to continue. Individual playback to any single endpoint is stable indefinitely. The issue is 100% reproducible and occurs within the first two or three track transitions of nearly every listening session.
This appears to be the same bug as ESU1GA (grouped zone playback drops at track transitions with 5 RAAT endpoints)
Roon Core
Hardware: Roon Nucleus (dedicated appliance)
Software: RoonServer v2.62 (build 1641) production
Network: Hardwired Gigabit Ethernet to unmanaged switch
Network
Ubiquiti Dream Router 7
Netgear GS116NA unmanaged switch (Nucleus and Couch - J2 endpoint both connected here)
Dedicated 5GHz/6GHz SSID on the UDR-7 for RoPieee endpoints only (separate from general household WiFi)
Grouped Zone Configuration
Zone name: Office - RME ADI 2 + Bedroom - J2 + Couch - J2
Three RAAT endpoints, all running RoPieee:
Endpoint|DAC|Connection|Clock Master Priority|Resync Delay
Couch - J2, Combo384 Amanero (Amanero Technologies), Wired Ethernet,1 (highest), 50ms
Bedroom - J2, Combo384 Amanero (Amanero Technologies), WiFi (5GHz/6GHz), Default, 50ms
Office - RME ADI 2, ADI-2 DAC (51100448) by RME, WiFi (5GHz/6GHz), Default, 50ms
Description of Issue
When playing music to the grouped zone, playback fails to advance automatically at track transitions. All three endpoints report dropouts simultaneously, Roon kills the stream with “Too many dropouts (>3s dropped out in the last 30s)”, and playback halts. The track does not advance. Manual intervention (pressing Next) is required each time.
Critical observations:
What I Have Ruled Out:
WiFi: The wired Couch - J2 endpoint drops out simultaneously with the two wireless endpoints. A WiFi fault would not affect the wired endpoint. WiFi is not the cause.
Group size: Tested 2-endpoint and 3-endpoint grouped zones. Failure rate is identical. This is not a throughput issue that scales with the number of streams.
Clock synchronization: Set Couch - J2 (wired) as clock master priority 1, 50ms resync delay on all three endpoints. No improvement.
Background audio analysis: Restricted to 01:00–05:00 window. No improvement.
Zone configuration conflict: After each reboot, manually rebuilt the zone group to ensure no overlapping zone configurations. Confirmed clean zone state before each test.
Log Evidence:
All failures follow the same pattern. The following is from a test session on March 28, 2026, playing a 142-track Tidal playlist immediately after a clean reboot and manual zone rebuild.
Session timeline:
21:09:56 — Playback starts. Couch - J2 (Combo384 Amanero) correctly selected as clock master.
21:11:01 — First track transition: succeeds. OnToNext → \_Advance (Track) → Playing. Clean, no hesitation.
21:11:08 — Second track (“My House - SHAGGO”, 24/48 TIDAL FLAC) begins playing.
21:11:15 — All three endpoints report \[12% buf\] at position 4:31/4:37. Buffer critically low with 6 seconds remaining.
21:11:20 — Still \[12% buf\] at 4:36/4:37. One second remaining.
21:11:22 — Dropout storm begins simultaneously on all three endpoints.
21:11:25 — “Too many dropouts. Killing stream.” InvalidOperationException cascade on multiple worker threads.
21:11:48 — BufferingTrack == NextTrack during ClearQueuedMedia, setting \_stop_on_next_track_transition. Playback halts.
Buffer drain before dropout
03/28 21:11:15 Trace: \[Office - RME ADI 2\] \[Enhanced, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:31/4:37\] My House - SHAGGO
03/28 21:11:15 Trace: \[Bedroom - J2\] \[Enhanced, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:31/4:37\] My House - SHAGGO
03/28 21:11:15 Trace: \[Couch - J2\] \[Enhanced, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:31/4:37\] My House - SHAGGO
03/28 21:11:20 Trace: \[Office - RME ADI 2\] \[Enhanced, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:36/4:37\] My House - SHAGGO
03/28 21:11:20 Trace: \[Bedroom - J2\] \[Enhanced 3.8x, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:36/4:37\] My House - SHAGGO
03/28 21:11:20 Trace: \[Couch - J2\] \[Enhanced, 24/48 TIDAL FLAC => 32/48\] \[12% buf\] \[PLAYING @ 4:36/4:37\] My House - SHAGGO
Dropout storm — all three endpoints fail simultaneously
03/28 21:11:22 Trace: \[Combo384 Amanero\] \[raatclient\] GOT \[13\] {“status”:“Dropout”,“samples”:18130}
03/28 21:11:22 Trace: \[ADI-2 DAC (51100448)\] \[raatclient\] GOT \[46\] {“status”:“Dropout”,“samples”:10723}
03/28 21:11:22 Trace: \[Combo384 Amanero\] \[raatclient\] GOT \[46\] {“samples”:16836,“status”:“Dropout”}
03/28 21:11:22 Trace: \[Combo384 Amanero\] \[raatclient\] GOT \[13\] {“status”:“Dropout”,“samples”:24000}
03/28 21:11:22 Trace: \[ADI-2 DAC (51100448)\] \[raatclient\] GOT \[46\] {“status”:“Dropout”,“samples”:24000}
03/28 21:11:22 Trace: \[Combo384 Amanero\] \[raatclient\] GOT \[46\] {“samples”:24000,“status”:“Dropout”}
03/28 21:11:25 Warn: \[Office - RME ADI 2 + Bedroom - J2 + Couch - J2\] \[zoneplayer/raat\] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Stack trace (consistent across all occurrences)
03/28 21:11:25 Critical: threadpoolsynchronizationcontext: System.InvalidOperationException: Attempted to Read() without access in Thread\[Id=111, Name=Worker (14)\]
at Sooloos.Concurrency.SharedObject`2.Read[U](Func`2 getval)
at Sooloos.Broker.Transport.RaatZonePlayer.ev_too_many_dropouts(Endpoint endpoint)
at Sooloos.Broker.Transport.RaatZonePlayer.Endpoint.OnDropout(Int32 frames)
at Sooloos.ThreadPoolSynchronizationContext.<>c__DisplayClass14_0.<\_Dispatch>b__0(Object )
This exception fires on multiple concurrent worker threads (threads 100–152 observed) in rapid succession as each endpoint’s dropout handler fires simultaneously.
Race condition flag — track transition halted
03/28 21:11:48 Info: \[Office - RME ADI 2 + Bedroom - J2 + Couch - J2\] \[zoneplayer\] BufferingTrack == NextTrack during ClearQueuedMedia, setting \_stop_on_next_track_transition
This flag causes Roon to halt at the end of the current track rather than advancing. Playback does not resume until the user manually presses Next.Steps to Reproduce:
Create a grouped zone with 2 or more RAAT endpoints (RoPieee on Raspberry Pi).
Play a Tidal album or playlist.
Wait for a track transition.
Dropout storm occurs at the transition; playback halts and does not advance automatically.
Reproduction is consistent within the first few transitions of every session.
Expected Behavior:
Grouped zone playback should transition between tracks automatically without dropping all streams or halting.
Workarounds Attempted (none effective):
Set wired endpoint as clock master priority 1 — no improvement.
Set 50ms resync delay on all three endpoints — no improvement.
Restricted background audio analysis to 01:00–05:00 window — no improvement.
Tested 2-endpoint grouped zones — fails at same rate as 3-endpoint groups.
Rebuilt zone group after each reboot to eliminate zone configuration conflicts — issue persists.
It would be good to know what the real facts are and what Claude hallucinated in your summary.
However:
I’m pretty sure that this is false and that Roon support stated in similar cases that in grouped playback the whole group is torn down if one of the members fails. I’d try the experiment with all endpoints wired.
I don’t understand. Are you suggesting that I didn’t read what Claude output?
As for the assertion that WiFi isn’t the cause being wrong. Ok, great. I’d love for someone from Roon Support to tell me that.
How would I know. People now post Ai slop all the time and it’s hard to tell, but humans shouldn’t have to guess and wade through it
Sure, it will take some time. Sorry for trying to help, it won’t happen again
Hey @Sean_Birdsell,
I can confirm that when playback is grouped, a dropout on the WiFi endpoint will cause the whole group to drop. What happens if you try using your Nucleus HDMI output as part of the grouped zone, does it stop with only one or specific zones? This test will tell us if one of the grouped zones in particular is causing this issue. If you are able to reproduce the behavior with System Output, please let us know the exact local time + date + track of the issue so that we can look over diagnostic errors associated with your account, thanks!
Happy to run the test and will be doing so shortly. However, when I was having similar trouble a year or two ago, I was told that grouping a DAC connected directly to the Nucleus via HDMI caused issues when grouped with networked endpoints (hence, why everything is a network endpoint now)
Ok. Test complete. I added an HDMI connection from the Nucleus to a Marantz Cinema 70s and then grouped it with the other three Roon endpoints (one wired, two wifi; all three RoPieee based). I then hit play. The song was:
title;artist;album;isrc
The Traveller;Art d’Ecco;Serene Demon;qmeu32314684
It started somewhere around 00:10:00 GMT and ended around 00:13:00 GMT and it has been sitting there stuck since. I’m going to stop playback now, but that should give you a place to start.
I repeated the test. This time with just the HDMI connection and the wired RoPieee. The song was:
title;artist;album;isrc
Smart World;Snapped Ankles;Hard Times Furious Dancing;gbckb2513406
I started playback at around 00:22:00 GMT and the song reached the end and failed to advance around 00:23:00 GMT. I think it’s safe to say it isn’t the WiFi.
I’ll look forward to hearing what you find.
Hey @Sean_Birdsell,
Thanks for the timestamps! From a fresh diagnostic report, we can see that in your grouped configuration, the Nucleus (HDMI) is acting as a clock slave to your Couch - J2 (the Master). The RAAT logs show the Nucleus struggling to keep its internal clock synchronized with the master. When the “neterror” or “offset” becomes too great at a track transition, the buffer underruns, leading to the “Too many dropouts” kill-switch.
As a next step in testing, could you please inverse the Clock Master: * Set the Nucleus HDMI A (Cinema 70s) as the Clock Master Priority 1 and set all other endpoints to “Default.”
It would also be good to test native Sample Rates.
Also, if you haven’t yet, I’d perform a fresh RoonOS install via the webUI.
Thanks, Sean!
benjamin,
Thank you for the assistance. I will try that test tomorrow night (EDT).
benjamin,
The first thing I did was a I reinstalled RoonOS. I then set the clock master settings as you described (Nucleus HDMI A (Cinema 70s) as the Clock Master Priority 1 and set all other endpoints to “Default”). I set up a group that included the Cinema 70s HDMI (wired), Couch - J2 (wired), and Office - RME ADI 2 (wireless) endpoints. I have not yet capped the max sample rate on each endpoint. Despite not doing that, I have played through about a dozen transitions without issue.
I have several questions. It would seem from this test that the J2 DACs (wired or wireless) do not serve well as the Clock Master, correct? The connection of the Nucleus using HDMI is not something I can maintain (I need that HDMI port); any suggestions for what I can use instead? Finally, why the desire to also test with with the sample rates capped? Much of what I listen to from Tidal is available at 24 bit, 48KHz.
Finally, this morning’s testing (my time) was relatively short. I plan on giving it a longer run this evening, so please don’t close the ticket quite yet.
Alright, I was able to do some more testing. I had to change a few things: first, I removed the HDMI connection to the Nucleus (b/c I need that port). So I was now back the Nucleus and one RoPiee J2 connected via ethernet and a second RoPiee J2 and an RME ADI-2 FS both connected via WiFi. I set the Clock Master Priority to 1 on the RME (thinking it has the best clock of the three); the other three were set to Default. I was able to reproduce the problem.
I then set Max Sample Rate (PCM) to “up to 48kHz” and Max Bits Per Sample to 24. 44.1 was not available to me as a choice on any of the three endpoints. After playing several songs, playback again failed at the end of a track. Here’s a very abbreviated edit of the log file from that stoppage:
04/08 23:27:12 [Local 04/08 19:27:12] Trace: [Office - RME ADI 2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [100% buf] [PLAYING @ 3:28/3:45] T&A - Blondshell
04/08 23:27:12 [Local 04/08 19:27:12] Trace: [Bedroom - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [100% buf] [PLAYING @ 3:28/3:45] T&A - Blondshell
04/08 23:27:12 [Local 04/08 19:27:12] Trace: [Couch - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [100% buf] [PLAYING @ 3:28/3:45] T&A - Blondshell
04/08 23:27:18 [Local 04/08 19:27:18] Trace: [Office - RME ADI 2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [72% buf] [PLAYING @ 3:33/3:45] T&A - Blondshell
04/08 23:27:18 [Local 04/08 19:27:18] Trace: [Bedroom - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [72% buf] [PLAYING @ 3:33/3:45] T&A - Blondshell
04/08 23:27:18 [Local 04/08 19:27:18] Trace: [Couch - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [72% buf] [PLAYING @ 3:34/3:45] T&A - Blondshell
04/08 23:27:23 [Local 04/08 19:27:23] Trace: [Office - RME ADI 2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:39/3:45] T&A - Blondshell
04/08 23:27:23 [Local 04/08 19:27:23] Trace: [Bedroom - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:39/3:45] T&A - Blondshell
04/08 23:27:23 [Local 04/08 19:27:23] Trace: [Couch - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:39/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Office - RME ADI 2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Bedroom - J2] [Enhanced 6.0x, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Couch - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Office - RME ADI 2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Bedroom - J2] [Enhanced 6.0x, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:28 [Local 04/08 19:27:28] Trace: [Couch - J2] [Enhanced, 16/44 TIDAL FLAC => 24/44] [8% buf] [PLAYING @ 3:44/3:45] T&A - Blondshell
04/08 23:27:29 [Local 04/08 19:27:29] Trace: [Combo384 Amanero] [raatclient] GOT [193] {"status":"Dropout","samples":1136}
04/08 23:27:30 [Local 04/08 19:27:30] Trace: [Combo384 Amanero] [raatclient] GOT [193] {"status":"Dropout","samples":17946}
04/08 23:27:30 [Local 04/08 19:27:30] Trace: [ADI-2 DAC (51100448)] [raatclient] GOT [38] {"status":"Dropout","samples":7964}
...and so on as the dropout storm happens...
Thoughts? Additional things I need to test?
There is nothing else to test as I’m pretty sure I’ve sorted it (with the help of AI reading those voluminous log files). It boils down to my ignorance about how taxing upsampling is and how negatively it effects a device like the Nucleus. As of right now I have this configuration:
It was the convolution filters and high res that I didn’t want to lose in grouped playback: I haven’t. Thank you very much for your help. I wouldn’t have gotten here without it.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.