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?

5

Hi @JOHN_HENRICK,

Let’s try to rule out some persistent connectivity issues with device discovery on Orbi mesh networks. Re-reading this report, it’s entirely possible that what you’re experiencing is unrelated to RAM/memory and more a result of multicast traffic failing to forward between mesh nodes in the manner that Roon expects. The two problems are likely interrelated - in either case, connectivity issues are much easier to resolve than RAM limitations.

Specifically, this symptom in your original post leads me to suspect this possibility:

“running Roon rock on Intel NUC with 16GB Ram
Randomly roon does not respond and app will not connect
some zones then stop playing”

In your Orbi mesh settings, have you unchecked the option for “Disable IGMP Proxying,” by chance? IGMP Proxying needs to be enabled to ensure that device discovery announcements carried by mDNS can forward between RoonServer, Roon Remotes, and endpoints.

Please also ensure any settings you see related to Multicast Forwarding are turned on.

Here’s a guide outlining all our recommendations for Orbi networks:

Please let us know if this helps. We’ll watch for your response and work from there. Do keep in mind that threads in this support section will automatically close after several days without any response from the user who submitted the original report.

Thank you!

6

Thanks for the update that option was disabled on orbi now enabled

Only device giving the roon rock issue is my samsung s24 ultra today

When it said not available a local tablet worked correctly

Will.continue testing

John

1 Like
7

Sounds good @JOHN_HENRICK, keep us posted on your findings!

8

Hi @JOHN_HENRICK,

This thread will shortly auto-close without any new responses. We wanted to check back in - how has the network performed with Roon since taking some of the steps in the posts above?

If you’re still having issues with the Android phone, try disabling some of the battery saver settings. These can interfere with Roon’s ability to access the phone’s network interface.

9

Roon not accessible this morning at 0730 from any device restarted roon server

10

Hello @JOHN_HENRICK

We’ve reviewed the RoonServer logs around the reported time and do not see any crashes, database faults, or server-side stalls. The server remains active and responsive internally.

However, the system logs show repeated NTP timeouts and peer invalidations, which strongly indicates intermittent network packet loss — particularly affecting UDP traffic.

This aligns with the symptoms you’re seeing (remotes losing connection, zones disappearing) and is commonly observed on mesh networks such as Orbi when multicast / IGMP forwarding is unstable.

At this point, the evidence points to a network-layer issue rather than a Roon Server failure.

Please confirm that IGMP Proxying is disabled. Try connecting the ROCK to the main node.

11

Have disabled IGMP proxying and moved to main node

music playback seems ok - slow response today when identifying albums at 14:06

any issues shown ?

12

Hi @JOHN_HENRICK ,

Thanks for the update! Moving the ROCK to the main Orbi node and adjusting the IGMP settings are great steps toward a stable network.

Regarding the sluggishness you experienced today (especially during album identification), with a library of 177,000 tracks, your NUC is under a significant load. To help smooth things out, I recommend two specific steps:

1. Reinstall Roon OS (Fresh System Files)

Sometimes, system files can be affected by power cycles or network drops. This process ensures the “engine” is running clean without touching your music or database.

  • Access your ROCK Web Interface (by typing the ROCK's IP address into a web browser).
  • Locate the "Operating System" section.
  • Click "Reinstall". This usually takes just a minute and can clear up performance bottlenecks.
2. Disable Background Audio Analysis

With a library of this size, background processing can compete for resources, making the UI feel slow.

  • Go to Settings → Library.
  • Set Background Audio Analysis Speed to "Off".
  • Set On-Demand Audio Analysis Speed to "Throttled".
  • Note: This frees up the CPU to focus entirely on browsing and playback responsiveness.
One quick question:

Do you use any other software (like a tagging tool or file manager) that might be editing your music files in the background? The logs show a high number of “dirty tracks,” which suggests something is frequently modifying your files, causing Roon to re-scan more often than necessary.

Please let us know if the responsiveness improves after these changes.

Thanks.

13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

14

The system seems very slow this week tried reboots have added some music and continue to correct tags but seems slow to start playing etc. - any help appreciated as trial is ending and due to sign up as permanent user

Timestamp today 17:53 22/02/2026

16

Hi @JOHN_HENRICK,

I’ve merged an abridged version your new post into your previous support topic, that was closed due to lack of activity.
I’ve also re-opened it.

Did you see the post from @alex_h above he some pertinent questions in order to establish the root cause of what’s going on here, I recommend reading his post and replying to him.

17

Many thanks i thought i had replied previously will do that now

18

Hi @alex_h,

Apologies I thought I had replied to this before.

  1. I have reinstalled the OS a couple of times seems to improve but slows down later.

  2. I had both set to throttled as I assumed new music needed to be analyzed once added, I will change as above and continue testing

  3. I am using mp3.tag to tidy up my music collection and lower the qty of unidentified albums correcting titles and art etc. after which I ask Roon to force rescan as files are stored on a NAS drive and it doesn’t seem to detect the changes. I assume this helps to clear up the dirty tracks identified?

19

latest update 18:56 25/02 system is very slow today trying to merge albums or even playing music - any obvious problems?

20

Hey @JOHN_HENRICK,

Thanks for the update and additional information! Unfortunately, from reviewing a fresh diagnostic report of your Roon Server, it appears your suffeirng from a known service outage caused by upstream DNS servers. Here is the tracking thread around the issue:

Our team is actively investigating this, though we don’t have immediate troubleshooting steps to share just yet. I truly appreciate your patience. We’ll be posting all updates directly to the tracking thread above as soon as we have news.