Intermittent Roon Remote connectivity issue on multiple devices (ref#ILRTRR)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· App interface looks or behaves oddly

Tell us what's going on

· For the last few weeks, I've been getting erratic behavior from Roon remotes. Sometimes on my iphone, almost always on my two Macs. I include a network topology below. I've tried to fix it by replacing my Netgear unmanaged hub, I also replaced my wifi router, and even tried replacing my Exasound server with a Nucleus branded one. Sometimes the problem goes away, but then it's back.

I've posted on this previously here: https://community.roonlabs.com/t/roon-remote-on-mac-flashes-intermittently-after-nucleus-installation-ref-qfok80/318821/2 but no one responded and I thought I'd figured it out, but no, it's back.

Topology:
High speed Verizon connecting to my Eero mesh. The primary Eero is wired to the server in the other room.

My Exasound can be found at delta.local (see screenshots).

The Exasound is connected by cat5 ethernet through the unmanaged gigabit hub to my PS Audio Airlens and then on to the DAC.

I can 'see' Roon when I launch the remotes. And then the logo flashes and it takes me to "uh oh something's not right" or to more flashing and then back to the home page or, rarely, where I was.

Sometimes the uh oh window will then let me connect to a 'new server' and then I see the green dot, but it can take up to 30 seconds to connect.

It's worth noting that my topology worked perfectly for years and years. I made no hardware changes except for my new Macbook pro, which wouldn't explain why the old macbook air doesn't work properly either.

Suggestions are welcome!

Tell us about your home network

· as above.

Hey @seth_Godin1,

Thanks for writing back in, and I’m sorry to hear you’re still hitting connectivity issues across your Roon Remotes.

First, we’re seeing a few different machines that have recently run Roon Server across your local setup. Could you please get your Nucleus hardwired directly to your primary router - reboot everything and then reproduce the issue and share a fresh date and time the next time things fall apart?

From there, we’ll be able to enable digansotic mode for your Nucleus to take a closer look into things.

In the meantime, it may be worth double-checking your macOS firewall exceptions to ensure Roon is listed as a proper exception:

Thank you!

thanks @benjamin

It’s always been hardwired. It goes from the base router via cat 5 across a few rooms to the exasound server.

I don’t have firewall turned on.

at 2026-04-30T20:53:00Z I rebooted the exasound and my macbook air. The macbook air can see the delta exasound, but shows a red dot, initializing, and stays there, flashing the word initialzing now and then. The macbook pro got to the last song I played, which is great, but it’s flashing every few seconds.

Is that what you need?

and then about an hour later, all flashing is gone on the macbook pro. The macbook air continues to have a red dot and cycles trying to connect. The iphone is fine.

2026-05-01T04:00:00Z I see (with no hardware changes, and with the server untouched) that both the iphone and the macbook pro can’t see the server. If I restart the server, I expect it’ll fix this for now.

Pursuing this on my own as I await expert insight, I removed the last unknown piece of hardware–the long ethernet cable from my kitchen core router to the living room. Now, I have the unmanaged hub connected by a shorter cat5 to the mesh router eero in the living room. So, there’s a wireless hop before it gets wired.

I thought that this fixed it!

alas, twenty minutes later I saw a few flashes

but it ‘seems’ slightly more stable, though this might be a placebo.

Given that it was stable as a rock for 5+ years (no pun intended, actually) I’m surprised that it’s persisting and curious as to why.

Open to thoughts

I let it ‘settle’ overnight (how can that matter, who knows?) and this morning, there’s no flicker for the first time in a month or so.

I’m going to ascribe this to a wonky cable that was creating some sort of echo. I’ll make this one as solved (frustration being the mother of invention) but will be back if it returns.

alas, next morning, phone and mac can’t see the server. Need to reboot (again).

Hey @seth_Godin1,

Thank you so much for your detailed write-up and for your patience. We’re sorry this has been such a persistent frustration, especially given how rock-solid your setup was for so many years. You deserve better than this, and we’re going to get to the bottom of it.

After reviewing everything you’ve shared, we have a strong lead on what’s causing this. Here’s our thinking:

The most likely culprit is a subnet and mDNS discovery problem. Roon relies on mDNS (the same underlying technology as Apple’s Bonjour) to find your server from your remotes. When your Eero mesh network and your wired segment end up on different subnets (which can happen silently after a firmware update on your Eero or Verizon gateway), mDNS traffic doesn’t reliably cross between them. The result is exactly what you’re seeing: the server is visible sometimes, then gone, temporarily fixed by a reboot, then broken again. It also explains why the problem appeared seemingly out of nowhere after years of stability. Something in the network layer changed underneath you, not in your Roon setup.

We also noticed that your Roon Server and remotes aren’t running the latest version, and there have been meaningful fixes to discovery and connectivity in recent releases. Updating should be one of the first things we tackle together.

Here’s what we’d suggest working through, roughly in order:

  1. Check for double-NAT. If your Verizon gateway and your Eero are both doing NAT, you’ll have two subnets by design. The fix is to put the Verizon gateway into bridge mode (or use IP Passthrough), so only the Eero handles routing. This alone may resolve everything.

  2. Confirm your devices are on the same subnet. On your Exasound server and your Mac, check the IP addresses. If one starts with 192.168.4.x and the other with 192.168.1.x, that confirms the subnet mismatch.

  3. Assign a static IP (or DHCP reservation) to your Exasound server. The pattern of the server disappearing overnight and after reboots points to a DHCP issue, the Server gets a new IP address, and your remotes are still looking for the old one. Locking it to a fixed address in your Eero settings is a simple, durable fix.

  4. Check Eero’s mDNS/multicast bridging setting. Eero has an option to enable mDNS across the network, please make sure it’s turned on.

  5. Update Roon on the server and all remotes. We’d like to do this in parallel with the network steps.

  6. As a quick diagnostic, try plugging your Mac directly into the same unmanaged hub as the Exasound via ethernet. If the problem disappears completely, that confirms the issue is in the wireless/Eero layer.

We’d also love to get your server logs, if you could bring your Exasound Roon Server and Roon Remote back online, we’ll enable diagnostics to take a deeper look.

A follow-up question for you: when your remotes are struggling to connect to your server, do they otherwise show up on your network without issue?

With that, we don’t currently have an Exasound unit in-house to attempt reproduction, but it would be good to review the webUI of your machine to confirm the performance monitor is showing a healthy system - another potential cause of your issues could be related to the physical network port on the machine itself.

You should be able to access the Exsound webUI by entering ‘delta.local’ in the address line of any web browser.

We’re confident this is solvable, and we’d like to stay closely involved until it’s completely behind you. We’ll make sure your responses get priority attention.

Thank you, Seth! :folded_hands:

Will check by Saturday. THANK YOU

Sounds good @seth_Godin1, we’ll be monitoring for your reply and results

okay, followed the steps, here’s an update

  1. there isn’t double NAT because I’ve removed the Verizon router completely. The line from Verizon goes right to the eero.

  2. They are on the same subnet.

  3. I assigned a DHCP reservation via the eero app and when I reboot the delta, it doesn’t change.

  4. in the eero app, DHCP & NAT are set to automatic

  5. I’ve consistently been updating all my servers and remotes every time it asks.

    I did all of this and it worked. Rock solid. I came back two hours later (nothing had been rebooted) and the mac and the phone “saw” the roon server, but wouldn’t play music, flashing a warning about a network error.

    I restarted both remotes, then they couldn’t see the server at all

    Then I restarted the server via delta.local and it all came back to life and it’s working again.

    so it’s a ‘ittle’ progress, but not enough. Thoughts?

fyi, you’re welcome to grab my server logs…

and

it’s working in this moment!

and

it always works when it’s hardwired to the unmanaged hub.

Hey @seth_Godin1,

Thanks so much for the reply and results! It certainly helps paint a clearer picture of what might be happening.

We were able to review a fresh diagnostic report from your Delta server and saw that the Delta server itself is completely healthy, which is good news.

We also see that the subnet mask is /22, not /24, which might be worth a closer look.

The Delta’s netmask is 255.255.252.0, meaning the network is 192.168.4.0/22, which covers 192.168.4.x through 192.168.7.x. This is fine and intentional, but it’s worth confirming that all your devices (Mac, phone, etc.) are also getting /22 masks from eero’s DHCP, and not /24.

A mismatch, where one device thinks it’s on /24 and another on /22, could cause exactly the kind of intermittent “I can see it but can’t talk to it” behavior you described.

To confirm this: On your Mac, go to System Settings → Network → your connection → Details → TCP/IP and confirm the subnet mask is also 255.255.252.0. Do the same on your phone if possible.

We’re also seeing the RAAT connection between your server and your Mac “bigmac” is dropping like clockwork, almost exactly every 56–60 seconds.

It connects, stays up for ~56 seconds, drops, retries 5 times over ~60 seconds, fails, then the remoting/serverconnectionv2 reconnect triggers and the cycle repeats.

A few troubleshooting steps that may help this:

  1. macOS System Settings → Battery (or Energy Saver) → uncheck "Enable Power Nap" and ensure "Wake for network access" behavior isn't interfering. Also check System Settings → Network → [your WiFi/Ethernet] → Details → TCP/IP for anything unusual.
BoomAudio / Camo Microphone virtual audio drivers - the logs show these are registered as RAAT audio devices on the Mac: BoomAudio and Camo Microphone. These are virtual audio drivers that can intercept or interfere with audio subsystem activity and are known to cause issues with Roon's RAAT protocol.

As a test: Quit Boom 3/BoomAudio entirely and remove Camo from the audio chain, then see if the 56-second drops stop. If they do, you’ve found it.

One thing we did notice on the Exasound machine - it appears that the root overlay filesystem (which is tmpfs-backed RAM) is completely full. This is how the Delta live OS works, but the 100% usage on the overlay could be abnormal and could explain why Roon occasionally goes unresponsive and needs a restart. When the overlay fills, any write operations (log writes, cache updates, database operations) will silently fail or cause the process to stall.

The cleanest fix is a full reboot of the Delta, which will reset the RAM overlay. But if it fills again after a day or two, that points to a memory leak or runaway logging in one of the Delta’s services. Give this a try, and we’ll review another fresh diagnostic report around that timeline to see how things look.

On another side note - I noticed you have a second ROCK Roon Server up and running. How has performance been on this machine?

I realize this is a lot of information to digest - thank you for sticking with us Seth, and certainly let us know if you have any questions along the way. :raising_hands:

Our support team isn’t around over the weekend, but we’ll be back first thing Monday morning, in case we don’t see a reply or update before the end of the day today.

amazing, and quite helpful, thanks.

it took quite a bit of hunting to find Boom and Camo, neither of which I’ve used for years, and then to find uninstallers. But they’re gone now!

The second Rock–I can only imagine that it’s related to the PSAudio server in my office. I haven’t used it in almost a year, are you seeing otherwise?

Here are the network settings of big mac and my phone.

Re the root overlay system on the exasound–I’ve done complete power down on the exasound when I needed to reboot, so that shouldn’t be happening, I think. Suggestions are welcome.

Anyway, now that the boom and camo are gone, I’ve rebooted and I’m hopeful we’ll see progress. Will let you know!

update at 2026-05-09T17:49:00Z

Still no flashing, appears rock solid. But on the mac AND the iphone, it won’t let me play anything. The play icon is disabled. Searches hang.

I rebooted the server and it worked again.

Hey @seth_Godin1,

Thanks for the update and additional information, I’m sorry you’re still having issues with your remotes!

We’ve escalated this issue to senior development for further analysis. We’ll be discussing your case tomorrow and should have more information to share from that.

In the meantime, I’m curious, if you open delta.local in a browser, is there a performance/storage panel available for review?

I’m wondering if the RAM overlay usage might be visible for you to see. The Exasound’s RAM overlay filesystem filling up could be a culprit for the “play button disabled / searches hang → fixed by reboot” pattern.

Thank you, Seth :folded_hands:

I rebooted in order to see delta.local and see these panels. that’s the closest to what you’re asking for I think.

Hey @seth_Godin1,

Thanks for sending over those screenshots! The system looks healthy overall — CPU is low (5% aggregate), temperatures are nominal (all well below critical), and memory usage is ~25% (3.9GB of 15.5GB). There is no resource pressure on the Exasound itself causing the drops

I think this rules out the “RAM overlay full” theory.

That said, another fresh diagnostic report does show similar RAAT session from “bigmac” drops after almost exactly 56 seconds, which feels more like a precise, repeating timeout.

In the eero app, check for any “smart” steering, band steering, or “optimize for gaming/streaming” options. If the hub is connected to a satellite eero node rather than the gateway eero, try connecting it to the gateway directly and see if behavior improves.

With that, we do still see a second active Roon Server running as well. I’d confirm in the eero app’s connected devices that no device named “ROCK” or similar is online. If the PS Audio unit is still broadcasting, disable Roon on it completely to remove it from the network.

From your screenshot - General Settings, it shows “Automatically update UPnP library” is enabled, and a library scan is actively in progress. While this isn’t causing the RAAT drops, it adds CPU and I/O load that can make the “play button disabled” symptoms worse when they occur. See if you can temporarily disable this toggle while troubleshooting to reduce noise.

Our development team will be reviewing your case further today, and should have additional information to share from that. Let me know if the above may help in the meantime! :raising_hands:

the roon rock thing is so weird! The unit in my office has been turned off for a year, so it’s not that.

Reminder: we had problems before I installed the eero and we had similar problems when I subbed in the new nucleus.

it’s a mystery.

eero app shows “client steering” as on.

when I’m home, will turn off the UPnP update