Intermittent "waiting for Roon server" messages across all remote devices (ref#DQS69E)

Support
1

What’s happening?

· I am experiencing freezes or crashes

How can we help?

· I am experiencing freezes or crashes

Other options

· Other

Describe the issue

Hi, I have been a Roon user since 2017. Starting earlier this week any endpoint I try to playback to has intermittent "waiting for roon server" messages and the audio zone playing temporarily disappears. This is happening across all endpoints. The core is on a NUC which is connected to my router via Ethernet (2gig FIOS fiber connection). No configuration changes were made to my setup before this issue began. I have tried restarting the Roon core a few times and this has not had an effect.

Describe your network setup

Deco BE63 mesh setup with the Roon Core hardwired ethernet to the main router. Fios 2gig fiber plan. Variety of endpoints.

2

Hello @Seth_Diamond ,

Thanks for reaching out. Can you please reproduce the issue and note the exact local time + date when you notice the behavior occur next time and let us know this info here so that we can enable diagnostics for the affected Server? Also, I am noticing several Roon Servers tied to your account, can you please confirm the specifications (Operating System / RAM) of the affected one so that we look over the correct logs? Thanks!

3

I only have one Roon server. Screenshot above. [moderated: screenshot removed because it shows private email address in a public forum]

I will try to play music in a bit and give you a timestamp for when it happens again. It is pretty consistent any time I try to play music right now. But you can also start looking at the above server (and let me know what other servers you see, I only have the one) to look at any recent play activity from the last three days.

4

Just happened again. 1:37 PM local time New York City. 2/25/25

6

Hi @Seth_Diamond ,

Thanks for sharing that timestamp, I was able to activate diagnostics for your Roon install and it looks like logs came in properly. I’m escalating the log traces to the team for additional feedback.

It looks like there was one additional device running Roon with 64GB of RAM, but double checking it, it looks like it’s running only the Roon interface in Remote mode while the 8GB device is the server, disregard my previous statement.

We will reach out once again once we have the team’s feedback on the error traces, thanks!

7

I’ve had a similar problem all week, and completely lost my Roon Ready connection from my DAC/Preamp to my Nuc. I spent several days trying things with no luck, then decided to unplug all my ethernet cables, powered down all my equipment, then unplugged the power to everything, re-hooked everything up and re-powered everything up and I’m back business.

8

Thank you, but I do want to confirm that this is not a successful solution here.

9

I want to follow up on this. It has been almost two weeks and this thread was going to auto-close tomorrow.

11

Hi @Seth_Diamond ,

Thanks for your patience while the team has had a chance to look over your case. Based on their feedback, it sounds like your network might be getting overwhelmed or experiencing some instability. To narrow things down, I’d recommend turning off all other Roon devices and just running one Core and one Remote for now. This can help isolate the issue and see if things stabilize.

If you notice that the problem only happens when you start playback, it could mean Roon is using all of your available network bandwidth. In that case, try reducing overall network usage—pausing large downloads, limiting streaming on other devices, or switching to a wired connection if possible. Let us know how it goes, and we’d be happy to help troubleshoot further!

12

Hi, this is not very helpful.

Based on their feedback, it sounds like your network might be getting overwhelmed or experiencing some instability.

Can you provide me the exact feedback or what was found in the logs? I have a 2gig FIOS setup with WiFi 7. I work from home and have no consistent issues with any internet dependent program outside of Roon. This is unique to Roon.

To narrow things down, I’d recommend turning off all other Roon devices and just running one Core and one Remote for now. This can help isolate the issue and see if things stabilize.

That does not solve the issue. I am confused as to why you believe I have multiple cores. I have one. I also never simultaneously use multi-room. I am generally using either a single instance of iPhone, an iPad, or a desktop remote to send music to an endpoint. What are you seeing in my logs that is inferring otherwise?

It’s unfortunately a very predictable occurrence where music is playing, then once or twice per song I see the “waiting for Roon core” graphic and music pauses. It is currently making the product unusable.

Please let me know next steps.

13

Hi @Seth_Diamond,

Sorry to hear the feedback hasn’t been helpful so far.

If you haven’t yet, can you temporarily hardwire one of your endpoints to your primary router, instead of one of your mesh nodes (same as your Roon Server) and see if the same issue occurs?

Roon is more sensitive to network conditions compared to other streaming services because of how it handles audio playback. Unlike apps like Apple Music or Qobuz, which use buffering and adaptive compression to smooth out playback over less-than-perfect networks, Roon streams audio in real-time with bit-perfect fidelity and minimal buffering.

If Roon is the only app showing network-related issues, it’s worth checking factors like Wi-Fi signal strength, network congestion, or whether a wired connection improves stability, as mentioned above.

Surely, here’s an example of a network failure in logging, leading to a disconnect with an endpoint:

Trace: [117] [raat_ll/client] [Ferrum Wandla] OnDisconnected: BeginRead SocketException(0)
Trace: [Broker:Transport] [raatserver] [Ferrum USB Audio] lost client connection. Retrying(1)

This means that Roon’s RAAT client was actively trying to read data from the Ferrum Wandla but encountered a socket exception, which typically indicates a network or USB communication failure.

We’re also seeing repeated failures around the Ferrum endpoint in relation to it’s ASIO driver:

"name": "Ferrum USB Audio"}, "external_config": {}}, "name": "Ferrum USB Audio", "error_message": "DeviceOpenFailed"}}

Do you have any other audio software that might be attempting to use the ASIO driver? If another program (e.g., a DAW or audio player) is using the Ferrum USB Audio ASIO driver exclusively, Roon won’t be able to open it. I’d also test out using different cables if you haven’t yet.

Also, I’d triple-check if your Ferrum USB Audio driver is up to date. If issues persist, try reinstalling it.

And lastly, if possible, in Roon, go to Settings > Audio, enable the WASAPI version of the DAC, and see if playback works. If WASAPI works but ASIO does not, it points to a driver issue.

If you disable the Ferrum device altogether, do you other devices still disconnect?

14

Thank you, this is much more helpful.

Can you take a look at some logs from 6:35PM EDT 3/18/25 and take a look?

I unplugged the Wandla and tried to play some music via the HDMI output of the hardwired Roon server. I got the same stutters in both the remote UI (waiting for Roon server graphic) and playback.

17

Hi @Seth_Diamond,

Absolutely - we were able to review the timestamp you’ve provided and saw the following:

First, several requests for audio blocks (FTMSI-B-OE) were interrupted and the system reported missing blocks -

[300] FTMSI-B-OE qo/96528FD9 interrupted req 1; missing block 38

Followed by multiple dropouts:

Trace: [64] [HD Audio Driver for Display Audio] [raatclient] GOT [13] {"samples":6861,"status":"Dropout"}
Trace: [64] [HD Audio Driver for Display Audio] [raatclient] GOT [13] {"samples":22050,"status":"Dropout"}
Trace: [64] [HD Audio Driver for Display Audio] [raatclient] GOT [13] {"samples":22491,"status":"Dropout"}
Trace: [64] [HD Audio Driver for Display Audio] [raatclient] GOT [13] {"samples":22050,"status":"Dropout"}
[64] [raat_ll/client] [HD Audio Driver for Display Audio] OnDisconnected: BeginRead ead count is 0

Followed by:

Warn: [Worker (5)] [nuc HDMI] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Trace: [Worker (5)] [nuc HDMI] [zoneplayer/raat] too many dropouts. stopping stream

The missing blocks and interruptions suggest buffer underruns due to network congestion or latency in retrieving data from Qobuz. Did you have other background tasks running when this happened?

While this might be a big ask - it might be worth testing out using a different machine as your Roon Server, temporarily, and see if you experience the same issues.

19

This solved the issue. I tried both using the new core on my desktop a floor above the router as a fresh install, then restoring my previous core from a backup. Generally when working as expected, when Roon core is being used, the NUC is not running anything else, including any intensive background processes, and right now it is still hosting the local files that the new core upstairs is accessing and playing without trouble.

In light of the above, any thoughts on how I can troubleshoot why there is so much latency coming from the NUC causing the dropouts, knowing bandwidth/network congestion is not the culprit?

20

Hey @Seth_Diamond,

Thanks for taking the time to test the above - and interesting results!

One thing to consider is the difference in RAM between your Windows PC and your NUC. Based on our admin view, your Windows machine has around 60GB of RAM, while the NUC is working with about 7GB.

While RAM isn’t always the cause of issues like this—and 7GB should be sufficient for your local library size—your Windows PC is a much more powerful machine overall. That could be a factor in performance differences.

One test you could perform on the NUC - remove 50% of your local library (temporarily) and see if there’s any change in performance.