Roon loses control of NAD C3050LE after playback actions (ref#6UXQVY)

[Mike_Jee]

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Hello Roon Support Team,

I would like to report a reproducible issue with a Roon Ready device and ask whether this behavior is expected or compliant with Roon Ready certification.

Device:
- NAD C3050LE (BluOS MDC2 module)
- Advertised and certified as Roon Ready

Environment:
- Roon Core: macOS
- Roon Core and the NAD C3050LE are on the same subnet
- Wired Ethernet connection
- No DSP, no volume leveling
- No grouping, no zones linked
- No VLANs or firewall rules

Observed behavior (100% reproducible):

1. After powering on, the NAD C3050LE appears normally in Roon under Audio Devices.
2. Playback starts and works correctly.
3. After a single playback control action such as:
- Pause
- Stop
- Track Change
4. Roon immediately loses control of the device, and shortly after:
- The NAD C3050LE disappears from Roon’s Audio Devices list.

Important observations:
- During this failure state, the device retains its IP address (verified via router DHCP list).
- The device remains fully controllable via the BluOS app.
- Network connectivity remains intact.
- Restarting the device restores Roon visibility temporarily until the issue is triggered again.

This suggests that:
- Network connectivity is not lost.
- BluOS native playback remains functional.
- The failure appears specific to the RAAT path or RAAT session/state handling within the BluOS firmware after certain playback state transitions.

My question:
- Is this behavior consistent with Roon Ready expectations?
- Are there any known RAAT compatibility or certification issues with the NAD C3050LE / BluOS firmware?
- Would you recommend any logs or diagnostics to confirm whether this is a device-side RAAT implementation issue?

I’m happy to provide Roon logs or perform any additional tests if needed.

Thank you for your time and support.

Tell us about your home network

· Single router setup, wired Ethernet.
Roon Core (macOS) and NAD C3050LE are on the same subnet.
No managed switches, no extenders, no mesh, no VLANs.
No VPN in use.

[vadim]

Hello @Mike_Jee,

Thank you for the detailed report — this is very helpful.

As a first isolation step, could you please try playing several tracks that all share the same sample rate and bit depth (for example, multiple 44.1 kHz / 16-bit tracks) and let us know whether the issue still reproduces?

In some cases, RAAT endpoints can behave differently during playback state transitions combined with format changes (sample rate / bit depth), and this test will help us determine whether the loss of control is triggered specifically by a format change versus a generic transport command (pause/stop/skip).

Please let us know:

• The exact sample rate of the tracks used
• Whether the issue still occurs when no format change is involved
• Exact timestamp when the issue appears next time.

Thanks — once we have this data point, we can advise on next steps.

[Mike_Jee]

Thanks for the clarification — happy to test.

I tested playback using multiple tracks with identical format:

• Sample rate / bit depth: [ 44.1 kHz / 16-bit]
• All tracks share the same format (no format changes between tracks)

Result:

• The issue does still reproduce when performing Pause / Stop / Track Change.
• The device does disappear from Roon under these conditions.

Timestamp of reproduction:

• [2025-12-27 22:09 UTC+8]

Please let me know if you would like me to capture Roon/RAAT logs immediately after the failure occurs.

Thanks vadim

[vadim]

Hello @Mike_Jee,

Thank you for the additional testing and for sharing the relevant log excerpts — this helps clarify what’s happening.

One critical detail stands out in the logs:

12/27 22:09:27 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] lost client connection. Retrying(0)
12/27 22:09:27 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] connecting (attempt 1)
12/27 22:09:27 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] connected
12/27 22:09:27 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
12/27 22:09:36 Info: [stats] 432028mb Virtual, 1226mb Physical, 1079mb Managed, 147mb estimated Unmanaged, 0.19% of runtime in GC pauses, 8ms last GC pause duration
12/27 22:09:37 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] lost client connection. Retrying(0)
12/27 22:09:37 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] connecting (attempt 1)
12/27 22:09:37 Trace: [raatserver] [RaatServer docker-roonserver @ 172.24.0.1:9200] connected

This confirms that Roon Server / RAATServer is running inside a Docker container.

Important clarification about Docker

Docker-based Roon Server deployments are not supported on any operating system.

This is not macOS-specific — Docker is explicitly unsupported regardless of platform due to how containerization interferes with:

• RAAT device discovery
• RAAT session state management
• Transport control transitions (play / pause / stop / seek)
• Network timing and keepalive behavior

While basic playback may appear to work, Docker introduces abstraction layers (virtual networking, NAT, container lifecycle handling) that can cause exactly the kind of behavior observed here, including:

{"status":"Lost","reason":{"reason":"setup"}}

occurring immediately after transport commands.

Because the server is running in an unsupported environment, we can’t determine whether this behavior reflects:

• a RAAT implementation issue on the NAD / BluOS side, or
• a side effect of containerized RAAT operation.

Required next step

To continue investigation and to evaluate Roon Ready compliance correctly, please:

• Stop and remove the Docker-based Roon Server
• Install and run Roon Server in a supported, native configuration
• Reproduce the same test (pause / stop / track change using identical 44.1 kHz / 16-bit tracks)

If the issue still reproduces in a supported environment, we can then:

• collect authoritative diagnostics on our side
• escalate the case to R&D
• involve NAD / BluOS if necessary for RAAT compliance review

Please let us know once you’ve tested in a supported setup and include the timestamp of reproduction.

[Mike_Jee]

Thanks for the detailed analysis.

I’d like to clarify one important point regarding the environment:

My Roon Core is running natively on macOS (Mac mini), not inside Docker.
In Roon Settings → General, the active Roon Server is shown as “mac-mini” (this Mac).

There is no Docker installation on this system, and Roon Server is not containerized.

Given this clarification, the behavior observed (endpoint loss after pause / stop / track change) is occurring in a supported, native macOS environment.

Please let me know how you’d like to proceed from here, and whether you’d like additional diagnostics captured under these conditions.

Thanks again for your help.

[benjamin]

Hi @Mike_Jee,

Thanks for the additional information - interesting the name the device RAATServer is losing connection to in that case.

We’re seeing two different macOS machines running Roon Server, do you see this issue no matter what machine is running Roon Server?

Please reproduce the issue, and share the specific track name when the failure occurs, as well as which Mac you’re running Roon Server on at the time of the issue.

Thank you!