Thanks for reaching out. Can you please let us know approximatly the time + date of the next crash? We’ll enable diagnostics mode for your account. When the crash happens, what are the exact symptoms you are seeing? Do you see the ROCK reboot, or are you presented with a waiting for your Roon Server screen? Or does music just stop with a specific error?
I’ll provide the date/time info upon the next crash. The last was Thursday, but worked okay last night after a reboot. I see two failure modes. First, upon opening the app, I see the waiting for Roon Server Screen. The second mode is different; the app opens normally and I choose music and press Play, but after a long pause, get a short message onscreen “Roon has lost connection to the audio device”. Both failure modes require a manual reboot of the NUC/ROCK, which normally restores proper operation. In the second mode, the audio device is a group of my Sonos speakers.
Thanks for that information. When you have a chance, please let us know the more precise timestamp of the crash and we’ll look over the logging for clues, thanks!
We’ve taken a closer look at logs and identified a few patterns around these connectivity events.
To clarify, we don’t actually see any evidence of RoonServer crashing in the last few days. The logs show that Roon is repeatedly unable to reach several Sonos players on the local network, with consistent “No route to host” errors on port 1400. That’s the Sonos control port; the ROCK is running and generating audio streams, but it cannot reliably communicate with all the Sonos devices in the group. In Roon, this generates the error you see: “Roon Lost Control of the Audio Device.”
Separately, the “Waiting for Roon Server” message in Roon corresponds in logs to a temporary communication delay between the remote and the ROCK. Roon Remote and Roon Server suddenly encounter a stale session, forcing the Remote to reinitialize the connection.
These intermittent connectivity symptoms differ in their underlying causes, but you can likely resolve both problems with some basic network configuration and settings changes.
Please try these steps:
Make sure all Sonos players are on the same network type—either all wired or all WiFi.
Power cycle your network in order: modem, router, switches, access points, Sonos devices, and finally the ROCK.
On the Leviton router, ensure IGMP or multicast handling is enabled, band steering is disabled, and client/AP isolation are disabled.
If you still have this issue with Sonos devices on a fully-WiFi setup, try hardwiring a single Sonos device. This will activate SonosNET, slightly changing how device announcements will forward between speakers.
These adjustments usually restore stable communication between ROCK, remotes, and Sonos endpoints. Please let us know if this helps.
Thanks Conner. I’m back here now because I have the “issue loading your library” failure just now when I opened the Android app for tonight’s music. I had several days since that failure last occurred. So I shut down music play for the night last night about 2130 EST. And opened the app again tonight 4 Feb at approximately 1723 EST. Between those times, the crash occurred. I will now have to shut down the NUC and reboot to recover. This has been the pattern for a very long time now.
Now, regarding you steps for the “lost control of audio device” problem. Haven’t had that one this week, but here goes:
1 I had all Sonos players on wifi for years, and started having this problem a year or so back. So based on advice here I did #4, and plugged one speaker hard wire to the router. That has not fixed the problem. So I had the Sonos failure both all on wifi and with one device hardwired.
2. I have routinely rebooted the entire network i that order, most recently last weekend. It has made no difference.
3. The router settings will be a challenge for me. Not my area of expertise. I’ll look into it when time allows. Won’t be before the weekend.
But having done most of these, and since the network worked great until about two years ago with the same network devices, I’m not optimistic.
The Sonos issue is actually less prevalent than the Rock crash. It’s the can’t find server thing that is the major pain in the a** as I have to do it as often as every night and at least several times a week.
Alex, restarting the Android app does not resolve the issue. I have to reboot the NUC/ROCK device. As I described, the crash occurred some time between 2130 on 3 Feb and 1723 4 Feb. Is there somewhere I can look on the app or elsewhere to give you the exact timestamp? I don’t see anything on the page with the “issue loading your library” message on the app.
Your best long-term solution here would be to restore from a previously saved backup that predates the issues you’re having. If you receive the same ‘issue loading your library’ then you’ll need to attempt to restore an older backup.
Is this something you’ll be able to do? If you don’t have any available backups, the other option would be to start completely fresh by resetting your Roon Database via the webUI.
We already did this a few weeks ago. On another thread here, Roon Support reached the same conclusion. So we did a complete Roon Database reset from the webUI. But the failure here continues to occur.
One of the issues here is that I have no way to really diagnose whether this is an issue with the hardware of my NUC, or is it a ROCK software issue. Having done the database reset already, are there any clues here that it is a hardware issue and not ROCK??
Roon crashed again tonight, 1831EST. Was playing music to three grouped Sonos speakers. The music abruptly stopped at that time. Initially, the app showed no audio devices found. I closed the app and restarted it, and this time the message was unable to find roon server. I’m off to reboot it now.
While our team previously identified database corruption as the culprit for the “Issue loading your library” message, the fact that this is recurring so soon after a complete database reset is a strong indicator of a hardware failure.
When a fresh database corrupts repeatedly, the most common cause is failed SSD or faulty RAM in your Intel NUC. If Roon attempts to write data to a physically failing part of the drive, the database becomes unreadable, which explains why the server “disappears” and requires a hard reboot to temporarily recover.
How high is the confidence level that my NUC hardware has failed or is failing? Replacing it means a significant to me investment in replacing it after just 4 years of service. I do not have an always on PC in the house, nor one with a hard wired connection, so running on an existing PC is not an option.
To add to the troubleshooting: We do not need to replace the whole NUC in such a case. The M.2 SSD, which hosts the ROCK OS and your Roon database, is the most likely hardware component to fail and cause intermittent crashes or “Waiting for Roon Server” hang-ups.
You can check the SSD integrity using software like CrystalDiskInfo (Windows) or DriveDx (macOS). Since ROCK doesn’t have a desktop interface to run these tools, you have two options:
External Enclosure: Remove the M.2 SSD from the NUC, place it in a USB enclosure, connect it to another computer, and run the health check.
Bootable USB: Create a bootable USB drive with a diagnostic tool (like Hiren’s BootCD PE or a Live Linux USB), boot the NUC from that USB, and scan the internal drive.
If the SMART data shows any critical errors or “Reallocated Sectors,” replacing just the SSD (a standard 256GB NVMe is very affordable) and reinstalling ROCK will likely resolve the stability issues completely.