Roon ROCK on Intel NUC becomes unresponsive with app connectivity issues (ref#WRMOLY)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Other

Please try to reboot your Roon Server

· Yes, rebooting helps, but the issue returns after some time

Please try to reboot your networking gear (Router/Switches/etc.)

· No, the issue is still the same even after a reboot

Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?

· No, the issue is still the same

Does the issue happen on multiple Roon Remotes (controllers) or just one?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I don't know how to do this

What is the operating system of your Roon Server host machine?

· Roon Optimized Core Kit (ROCK)

Describe the issue

running Roon rock on Intel NUC with 16GB Ram
Randomly roon does not respond and app will not connect
some zones then stop playing
Anyone advise what is the issue ?

Describe your network setup

Orbi Mesh Network

2

Hello @JOHN_HENRICK,

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

From what you’re describing, the behavior (Roon becoming unresponsive, zones stopping, and remotes losing connection until a reboot) typically points to either a network discovery / transport failure or a system-level stall on the ROCK itself, rather than a single app issue.

To move this forward, we need a bit more precision around how and when the failure happens.

Could you please confirm the following:

  1. Does this affect all zones and all remotes at the same time, or only a specific device (for example, one streamer or one control device)?
  2. How often does this occur?
    – multiple times per day
    – once every few days
    – once a week, etc.
  3. After you reboot the NUC and Roon starts working again, how long does it typically stay stable before the issue returns?

Most importantly, next time the problem occurs:

• Note the exact local time when Roon becomes unresponsive or zones stop
• Report that timestamp here

That timestamp lets us pull the diagnostic snapshot from the ROCK and see what actually failed (network stack, RAAT, database, storage I/O, or OS-level stall).

Since you’re running an Orbi mesh network, it’s also important to confirm whether this is happening across the whole system or if one endpoint is dropping first and cascading the failure. Is your ROCK and zones connected to the same node? I it possible to temporarily connect it to the single access point and check the same?

Once we have the timestamp and scope (all devices vs one), we can identify whether this is:

• network multicast disruption (common on mesh systems),
• ROCK OS instability.

Looking forward to your update — that will allow us to move this from “symptom” to “root cause.”

3

Hi again

device very slow again from 12:19pm very slow starting songs and sreaching

rock is connected to a satellite for information

i ahve 177000 tracks and the rock has 16gb of memory

JOhn

4

Hey @JOHN_HENRICK,

Thanks for the timestamp! There are several things within the Roon Server logs that plausibly explain sluggish playback start and slow search, and they mostly point to Roon Server being very busy doing background work, rather than a clear Sonos device fault.

The biggest thing we see is quite a large library churn (this is the biggest red flag)

This line is extremely significant:

[library] finished with 92543 dirty tracks
3894 dirty albums
15794 dirty performers
24564 dirty works
74415 dirty performances
150134 changed objects

We’re also seeing heavy album identification + cloud calls:

Identifying album [Various Artists - Romancing The'60s My Special Angel]
POST to https://api.roonlabs.net/... returned after 792 ms

Why this matters:

  • Roon is doing:
    • Album identification
    • Metadata matching
    • TIDAL integration lookups
  • ~800 ms per cloud call isn’t terrible, but multiplied across many albums, it adds up
  • This work competes with:
    • Playback orchestration
    • UI/API responsiveness
This reinforces that the Server is under sustained background load. With that, we’re also seeing very large, very complex Sonos topology.

You have:

  • Many Sonos zones
  • Multiple HT setups with satellites
  • Mixed wired + wireless
  • Some on 2.4 GHz, some on 5 GHz
  • Frequent zone state updates
This line repeats many times: 
Trace: [endpoint/sonos] zone update:  ...

You also have many Roon API clients connected simultaneously:

[apiclient 192.168.1.49]
[apiclient 192.168.1.57]
[apiclient 192.168.1.72]
[apiclient 192.168.1.97]

Each one receives zone change events, increasing Server workload during busy periods.

This does not indicate a fault, but it amplifies sluggishness when the Server is already overloaded.

Your RAM size versus library size should be fine - I do see from your account admin:

Tracks identified: 113,259

Total tracks in library: 172,321

There seems to be ~60k tracks that are not identified within Roon itself. Is this something you’d be able to improve?

If you temporarily disable all Sonos-related endpoints and only play to the system output of your Roon remote, do you still experience the same slowness?