· Grouped zone playback consistently drops out at track transitions when 5 RAAT endpoints are grouped together. Individual playback to each endpoint is stable for hours. The issue is reproducible and occurs multiple times per listening session.
Tell us about your home network
· Network
UniFi UXG Lite gateway UniFi US-16-PoE 150W switch 3x UniFi APs (2 wired, 1 mesh) All RAAT endpoints on the same VLAN/subnet (10.0.0.0/16) IGMP Snooping enabled, mDNS enabled, Multicast to Unicast enabled on WiFi Mix of wired and WiFi endpoints (WiFi endpoints on dedicated 2.4 GHz SSID)
Thank you for this exceptionally detailed bug report. It is rare to see such a high level of technical analysis, and the stack traces you’ve provided are very illuminating regarding the SharedObject.Read() exception.
Before we dive deeper into the threading behavior of the zone player, we need to address a few foundational points to stabilize the environment for official support:
As you may be aware, Roon does not officially support Docker installations, including the Unraid container setup you are using. While we recognize your hardware (i5-13600K) is more than capable, the virtualization of the networking stack and thread scheduling in Docker can introduce variables that are difficult to account for in RAAT synchronization.
To rule out the container environment as the culprit, are you able to reproduce this issue using a supported configuration (e.g., a native RoonServer installation on a standard Ubuntu/Windows/macOS partition or a dedicated ROCK NUC)?
When 5 zones are grouped, Roon’s clock synchronization is only as stable as the most “difficult” endpoint in that group.
Have you tried testing smaller groups (e.g., 2 or 3 endpoints) to see if a specific pair or a specific DAC (like the DragonFly or the NuForce) triggers the dropout?
If you remove the WiFi-based endpoints and only group the fully wired ones, does the issue persist?
Please remove the one endopint at the time and isolate the problematic one.
Since the failure occurs specifically at track transitions (where sample rates or clock headers often change), have you tried adding a Resync Delay?
This gives the DACs and the RAAT buffer more time to “settle” during the transition before the stream starts, which often prevents the race condition you are seeing in the logs.
Please try the Resync Delay first, as that is the most common fix for transition-based dropouts. If that fails, please try to reproduce the issue on a supported (non-Docker) setup.
Once you have a reproduction on a supported setup, please provide a fresh timestamp (Date and Time) so our engineering team can look at the diagnostics without the “noise” of the Docker environment.
