1GB fiber connected to a Ubiquiti UDM-Pro router. Most of my endpoints are connected via GbE.
The image below shows a number of endpoints that are clearly connected to the network (see lower left frame, MicroRendu, Wiim Mini Pro, PiFi Streamer, etc.)
It’s clearly not a network issues as I can ping all of these devices without issue. But as you can see the Roon client doesn’t see any network devices. these will often reappear after restarting the core but then the just disappear again.
I’ve had major issues with Roon Core since the April update (see other thread that IMO was prematurely closed).
Oddly enough, when I remote into the unit that is running Roon Core and open the client there it does see the endpoints, but none of the other client devices (macOS and iOS devices) can see the endpoints.
Since you’re running macOS, the behavior you’re seeing is consistent with the newer, stricter Local Network permission controls in the recent macOS releases.
Please try the following steps:
Open macOS System Settings → Privacy & Security → Local Network
Make sure Roon and Roon Server are both enabled
Even if they are already enabled, please toggle them off and back on
Fully quit Roon Server from the macOS menu bar / task bar
Reboot your Mac
After reboot, launch Roon again and check if the devices is avaliable again.
Once these permissions are refreshed and the system restarted, your audio devices should reappear.
Please let us know if the issue persists after these steps, and we’ll continue from there.
The image on the left is a macOS client (MacBook Pro) and the image on right is the client running on the Roon Core machine.
I’ve let it run for hours and it doesn’t ever finish. Ultimately end up shutting down the Roon client and restarting the Roon Core to bring it back online
That’s okay then and a good thing, because this additional annoying (because it keeps having to be retoggled and apparently can’t be avoided) hurdle was added by Apple with Sequoia. So, whatever the issue is that you are experiencing, at least it can’t be this.
Thank you for the clarification regarding your macOS version. Since you are on Monterey (via OCLP), you are correct that the “Local Network” toggle isn’t applicable here—my apologies for any confusion there.
Looking at your latest screenshot, I want to clarify one very important point: The “Snapshotting databases for backup” message explains why the client is stuck. When Roon performs a database backup, it pauses database operations to ensure data integrity. During this time, the Roon Client will show that “Loading…” status indefinitely because it cannot interact with the Core while the snapshot is in progress. If your library is large or stored on a slower drive, this process can take significant time.
Regarding the endpoints vanishing: Since you are using OCLP to run Monterey on unsupported hardware, please keep in mind that network stack stability can sometimes be affected by the patches used to support your specific hardware. If your endpoints continue to vanish outside of backup windows, we strongly recommend migrating to a more stable, natively supported platform. Given the complexities of running patched software via OCLP, the most reliable way to ensure a consistent experience is to move the Roon Core to a dedicated, officially supported environment.
Are you still seeing these issues outside of the scheduled backup windows, or is this “Loading…” screen the main thing stopping you from listening?
It seems that OCLP on the old mac mini just doesn’t work very well. I just wish I could have avoided the upgrade altogether since the older version was rock solid on this equipment. You really need to let your dev team know that adding some simple code that does an OS check (“if OS < macOS 12, abort upgrade”) and better release notes would save your team and many customers like myself a lot of headaches.
As you can see I’ve been a very happy Roon customer for over a decade, but this latest experience has me seriously looking at alternatives (if my subscription was up I probably would have moved on already but it just renewed in March).
So my next question … since ROCK doesn’t work well on a Intel based MacMini I’m guessing DietPI is probably the next best answer if I don’t want to trash the hardware?
Thanks for the reply, we definitely empathize with your frustrations. On the DietPi question: Yes, DietPi on that Intel Mac Mini is actually a solid path, and probably better than ROCK for that hardware. A few thoughts:
ROCK is optimized for NUCs and doesn't officially support Mac hardware, so the instability he'd hit there is expected
DietPi running on Linux (Ubuntu or Debian base) would give you a clean, lightweight OS without the OCLP patchwork, and Roon Server on Linux is very well-supported
The process involves creating a bootable Linux USB, installing it on the Mini, then installing Roon Server, not trivial but well-documented
Some caveats: you’d lose macOS entirely on that machine (or need to dual-boot), and onboard WiFi/Bluetooth on older Mac Minis can need extra Linux drivers, though for a server machine that's hardwired via GbE anyway it's largely a non-issue.
Let us know if there is anything else we can help with, thanks Eric!
. Do you know what version does provide this option?