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

Support
1

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.

2

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.

3

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

4

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.

5

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.

6

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!

7

Hi @Mike_Jee,

We’ll need to clarify a few details in order to take action from here as a team. To confirm we’re looking at the correct server logs and timestamp, can you please share one of the following?

  1. the name of the track that was playing or had last played when Roon lost control of the NAD C3050LE

  2. an approximate timestamp of the event

We’ll watch for your reply. Thank you!

8

Add images

</Test completed as requested.

Current setup:

  • Single Roon Server running on mac-mini
  • All other Macs are Roon Remotes only

Reproduction details:

  • Track: [Artist:Katie Melua
    Album：In Winter
    Track Name：River]
  • Format: 48kHz / 24-bit
  • Roon Server machine: mac-mini
  • Time of occurrence: [20:41 UTC+8]

The issue still reproduces:
After pause / stop / track change, control of the NAD C3050LE is lost and the device disappears from Roon
Please let me know if you’d like fresh diagnostics captured at this point.

截屏2026-01-06 14.51.33
截屏2026-01-06 14.51.331234×844 59.5 KB

9

Hi @Mike_Jee,

We’re unable to connect and enable diagnositcs on your Mac Mini running Roon Server, can you please use the directions found here and send over a set of logs to our File Uploader? Once logs have been uploaded, please let us know so that we can check the server for your files, thanks!

10

I’ve uploaded the RoonServer Logs.zip to the File Uploader.
The issue was reproduced shortly before capturing the logs.

11

Hi @Mike_Jee,

Thank you for the report. We’ve captured what we were looking for and will discuss it further with our development team.

Follow-up questions for you:

  1. Does this issue happen no matter how you issue a pause/stop/next command? For example, if you issue this command on the NAD device itself, does the same issue occur?
  2. Or, if you use different Roon remotes, does the same issue occur?

Thank you!

12

Thanks for the follow-up.

Regarding your questions and for additional context:

  1. The NAD C3050LE does not have physical Pause / Stop / Next buttons on the front panel itself.
    These playback controls are only available via the NAD infrared remote control.
    At the moment, I’m not physically with the unit, so I’m unable to test issuing pause/stop/next via the NAD remote right now.
    Once I’m back with the system, I can test this if needed.

  2. Yes — the issue occurs consistently regardless of which Roon Remote is used.
    I’ve confirmed the same behavior using Roon on macOS, iPadOS, and iOS.

Additionally, under the same Roon Core, network, and control actions, other Roon Ready devices on this network (Onkyo and Bluesound VAULT) do not exhibit this behavior and operate normally.
The issue appears isolated to the NAD C3050LE.

Please let me know how you’d like to proceed from here.

13

Thanks for the update @Mike_Jee - our team is in the process of attempting to reproduce this issue on the C3050LE, and so we should have more information once this takes place.

In the meantime, if you haven’t already:

  1. Please test out performing a factory reset on the device
  2. Check for any firmware updates for the device - and if none, reinstall the latest firmware version.

Thank you for your ongoing patience in the meantime! :raising_hands:

14

Quick update after further observation:

After the BluOS hardware reset, Roon playback control has been mostly stable.
However, I’ve since encountered an instance where AirPlay was unable to connect to the C3050LE.
Performing another factory reset restored normal operation again.

This suggests that both RAAT (Roon) and AirPlay are affected by the same underlying BluOS state issue over time.
I’ll continue observing and can provide timestamps if the issue reoccurs.

1 Like
15

Thanks for the update @Mike_Jee - certainly let us know if the issue reproduces.