Connection handling issue with Denon AVC-X3800H endpoint on RoonServer (ref#PRAFVH)

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

· There is an issue on RoonServer handling the connection with one of my endpoints : Denon AVC-X3800H.
Roon Server v:2.66(1658) on Ubuntu 2204 on QNAP.
Everything works perfectly with all my endpoints, including Denon AVC-X3800H, with the following exception after a specific sequence:
- start playing anything on Devon
- turn-off Denon via IR or Web API
- after some time, maybe a minute or so, as per Roon Server logs the tcp connections to Denon are disposed
- trying to turn-on/play from Ron on Denon will result in no action and critical errors being logged in Roon logs: NullReferenceException as if trying to reuse the former connection that was disposed on Denon turn-off
A restart of Roon Server fixes the problem (not convenient indeed).
Notice that if I turn off Denon through Roon endpoint convenience switch everything works properly.
The issue only appear if the power state change in Denon is initiated by someone else than Roon.
Notice that after turning off Denon its network is still functioning and it can be controlled by all means other than Roon.

Tell us about your home network

· Not relevant as everything works properly excluding the above sequence.

2

Hello @Gianluigi_Guida,

Thank you for the extremely precise diagnostic report. You have successfully isolated a specific race condition in the Roon RAAT implementation when it handles external power-state changes for Denon AVRs.

Since your Roon Server is currently entering a NullReferenceException state when the Denon’s power is toggled externally, it suggests that the Roon RAAT handshake is attempting to poll a TCP connection that the Denon has already terminated or transitioned into a “power-save” state without notifying the Roon endpoint controller.

While you are correct that this is a Roon-side software behavior, there is a limit to what we can patch in the Roon RAAT service if the Denon firmware is not sending the correct “Goodbye” packet to the network controller upon an IR or Web API power-down.

Recommended Path Forward:

  1. Report this to Denon (Sound United): Please file a support ticket with Denon regarding your AVC-X3800H. Specifically, mention that the receiver fails to send a proper network disconnect/idle signal to external controllers when powered off via IR or the Web API. If they can update the firmware to ensure the network card sends a notification or properly closes the socket upon power-off, Roon will be able to handle the re-connection logic correctly.
  2. Use the Roon Convenience Switch: As you noted, using the Roon “Convenience Switch” (powering off via the Roon interface) works perfectly because, in that sequence, Roon is the initiator of the power-down, allowing it to gracefully close the connection and reset the RAAT socket before the Denon goes into standby. Until Denon releases a firmware fix to align their power-state reporting with standard network protocols, sticking to the Roon power toggle is the only way to avoid the NullReferenceException loop.

I will flag your report for our RAAT development team to review, but since this relies on the Denon’s network standby behavior, a firmware update from Denon is the only true “fix” for this specific sequence of events.

3

Thank you for your prompt response.

Regarding your diagnosis/comments, please note the following:

- I’m fairly certain (let’s say 85%. :wink: ) that this issue appeared with the latest version of Roon (2.66). I’ve had the same setup in my home theatre and smart home for years and have never encountered this issue. It’s now a systematic problem.

- I don’t want to get into a discussion about technicalities and liability, but, having served as CTO, I believe I have some knowledge on the subject, and it appears to me that this isn’t a race condition, but rather a simple bug in the Roon RAAT server. If you have a null reference, it means you’ve been notified that the connection is no longer available and it’s your responsibility to reinitialise it. There can be a variety of reasons why a connection is lost, and the parties involved should handle it. But, as I said, I’ll stop here with the technicalities.

- I am not going to enter a discussion with Denon about this. First, Denon seems to be working properly. Second, it’s Roon-Ready, which means it uses your libraries and is certified by you. Therefore, if that were helpful, it would make sense for Roon Labs to communicate with Denon. (By the way, aren’t Roon Labs and Denon part of the same group?)

- I can’t use the Roon Convenience Switch feature in certain contexts. The receiver is part of a home theatre system and has its own external triggers and controls. Even so, the system has always been working properly.

I can try to find a workaround on my own, but not sure will find one and I hope you consider this issue a bug in the Roon libraries and something that seriously impacts the functionality of my home theatre system.

Roon is a great product, and I hope I won’t regret purchasing a lifetime subscription.

Best regards,
Gianluigi

5

Hello, just a touch base on the above topic:

Updated today the Roon Server with version 2.67 but unfortunately the connection management problem is still there

To clarify/simplify the above described problem :

  • The problem occurs when a streaming connection is dropped while playing, which seems to ‘nullify’ a socket reference which in turns makes the endpoint no longer reachable until a restart of Roon Server
  • I have not tested it but it’s reasonable to think that this may happen to any Roon Ready device, not just the Denon, when a streaming connection is dropped. Having then to restart the server I think is inconvenient

I will no longer bother you wth this, unless you may need further info/log-files, but would appreciate to know if there will be a follow-up on your side.

Best,
Gianluigi

6

Totally agree - if it’s ROON ready then ROON should follow up with Denon…

7

Hi @Gianluigi_Guida,

Thank you for the logs and for the detailed follow-up in your last post — they were genuinely useful.

We have reviewed the provided logs and were able to identify the failure sequence on our side. We have passed the findings to our partner team and asked them to attempt an internal reproduction. We have also created a task for our engineering team to review the logs in detail.

We are not able to provide a timeframe at this point, but the issue is on our radar. We will update this thread if there is any progress.

Thank you for your patience.