Roon frequently unresponsive to play commands and slow navigation (ref#V8QXNF)

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Tracks take a long time to play

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 was able to change my router's DNS servers but it did not help

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

· Roon Optimized Core Kit (ROCK)

Timestamp of issue occurrences

· I don't have timestamps at the moment

Describe the issue

Quite frequently Roon will not respond to the play command. I'll press play and just wait and nothing happens. If I navigate in Roon, it will often say 'Error loading saved page'. I close and reopen the app multiple times and try again - sometimes it will eventually play. Sometimes I have to reboot ROCK via the web UI. In most cases this will get playbook working speedy again, but on some occasions, I have to power down and power on the ROCK from the physical power button. That is always the most reliable way to get Roon responding to play commands at an acceptable speed, however all these fixes are just temporary. The issue always returns within a day or two. At times when I can't take it anymore, I just use the Tidal app, which NEVER has any delay whatsoever when either using Tidal Connect or AirPlay to my speakers. It would be great if support team could review the logs to see what could possibly be causing this frustrating issue. Also I only use Roon to play music from Tidal, and the ROCK is connected to switch via Ethernet.

Describe your network setup

I have 1Gb / 90Mb Internet connection. I'm using Amazon Eero 7 - 3 in total throughout the house. I have 3 network switches with 2.5Gb uplinks to the Eero's.

Hello @Glenn_Tesoriero

I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.

However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.

First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.

Hi, apologies for the delay, but Roon has been functioning quite well up until now. So it just randomly stopped playing my Tidal playlist. The UI still had the pause button visible like it would if it was actually playing, but nothing was responding to me tapping on any navigation controls. I closed and reopened the app multiple times and after about 4 minutes, was able to resume playback. 1 minute later it stopped playing again, and there was a message related to Tidal being slow, and then shortly after I could play again.

The initial issue occurred at 6:08UTC.

Hi @Glenn_Tesoriero,

The Tidal API upon which Roon relies takes a different network pathway and relies upon different servers than the Tidal native app and web player.

Sometimes, Roon Server can reach Tidal and buffer track content without issue, but the samples don’t reach the endpoint(s) reliably. Dependong on the point of failure, this can sometimes masquerade as an upstream problem with Tidal’s media servers not responding quick enough.

Logs show that this occurred several times here. Samples fail to reach two separate Bluesound endpoints in time, and the buffer lost pace with the audio stream. Here’s an example from logs last week:

05/15 06:47:10 [Local 05/15 16:47:10] Trace: [Bluesound PULSE FLEX 2i @ 192.168.20.114:36765] [raatclient] GOT [29460] {"samples":22022,"status":"Dropout"}
05/15 06:47:11 [Local 05/15 16:47:11] Trace: [Bluesound N131 @ 192.168.20.111:40127] [raatclient] GOT [20170] {"status":"Dropout","samples":22022}
05/15 06:47:11 [Local 05/15 16:47:11] Trace: [Bluesound PULSE FLEX 2i @ 192.168.20.114:36765] [raatclient] GOT [29460] {"samples":22022,"status":"Dropout"}
05/15 06:47:11 [Local 05/15 16:47:11] Trace: [Bluesound N131 @ 192.168.20.111:40127] [raatclient] GOT [20170] {"status":"Dropout","samples":22022}
05/15 06:47:11 [Local 05/15 16:47:11] Trace: [Bluesound PULSE FLEX 2i @ 192.168.20.114:36765] [raatclient] GOT [29460] {"samples":22264,"status":"Dropout"}
05/15 06:47:12 [Local 05/15 16:47:12] Trace: [Bluesound N131 @ 192.168.20.111:40127] [raatclient] GOT [20170] {"status":"Dropout","samples":22264}
05/15 06:47:12 [Local 05/15 16:47:12] Trace: [Bluesound PULSE FLEX 2i @ 192.168.20.114:36765] [raatclient] GOT [29460] {"samples":22022,"status":"Dropout"}
05/15 06:47:12 [Local 05/15 16:47:12] Trace: [Bluesound N131 @ 192.168.20.111:40127] [raatclient] GOT [20170] {"status":"Dropout","samples":22022}
05/15 06:47:12 [Local 05/15 16:47:12] Trace: [Bluesound PULSE FLEX 2i @ 192.168.20.114:36765] [raatclient] GOT [29460] {"samples":22022,"status":"Dropout"}

The missing samples in this case are consistent, which points to a traffic management issue rather than WiFi interference. We have a few Eero settings recommendations that can help prevent this type of behavior from occurring.

Where are the Bluesound units connected relative to the server in this Eero network topology? Are there multiple nodes in between them?

We’ll watch for your reply. Thank you!

Hi Connor,

Thanks for the analysis.

The Eero mesh that I have was a recent “upgrade” in an attempt resolve the issue, as I had read that my previous mesh hardware had reports of poor WiFI performance.

Here is a basic diagram of the network topology.

I reviewed the provided Eero Mesh Networks guide, and I have already configured a custom /24 single class C block. I’ve also set Cloudfare DNS servers.

Cheers,
Glenn

Hi @connor

Just posting to keep the ticket open and to check if you have any update?

Cheers,

Glenn

Hi @Glenn_Tesoriero,

Thanks for the screenshot and additional information! From a fresh Roon Server diagnostic report, we can see that your MBP remote is constantly changing IP addresses, appearing at four different IPs across the logs.

Every time the MacBook’s IP changes, Roon’s RAAT server loses the connection, spends 10+ seconds timing out (no data received for >10000ms. Killing connection), then frantically retries across the old IP before eventually discovering the new one. This could very well be causing your play delays.

As a next step in troubleshooting, see if you can assign Static/Reserved IPs to all Roon-Related Devices.

In your Eero app:

  1. Go to Connected Devices → find Glenns-MacBook-Pro → assign a DHCP reservation (static IP)
  2. Do the same for your ROCK, BlueSound Node, and Flex speakers
  3. This prevents Roon from ever "losing" a device mid-session due to an IP change
Also on the MacBook itself: go to System Settings → Wi-Fi → Details → TCP/IP and confirm it's not set to a manual IP that conflicts, or just set it to DHCP and let the Eero reservation handle it.

Roon uses mDNS/multicast for device discovery across the network. Eero mesh systems sometimes struggle with multicast traffic across nodes, a device on one Eero node may not be reliably discoverable by devices on another node. This can explain why the MacBook is seen as “gone” and then “rediscovered” repeatedly.

  • In the Eero app → Settings → Troubleshooting or Advanced, look for options around IGMP Snooping or Multicast
  • If available, try enabling IGMP Proxy or disabling multicast filtering

Let me know if this helps at all, thank you! :folded_hands:

Hi,

I use both wireless and ethernet interfaces on my MBP, so perhaps that is why it’s showing multiple IP addresses? Also, I use my iPhone as the remote most frequently, so the delays I see are usually from that device.

However, for the purpose of testing, I have followed your suggestion and configured DHCP reservations for all BlueSound devices, all remotes (MBP (both interfaces) and iPhone), and the ROCK.

I couldn’t find any configuration options around IGMP Snooping or Multicast in the Eero app, so will just monitor to see if the changes I made help.

Thanks,

Glenn

Sounds good, thanks for the reply @Glenn_Tesoriero, we’ll be monitoring for your reply and results :+1:

I think since the changes, even though it hasn’t been long, I feel the issues are still occurring, but it’s recovering faster. Whereas prior, I would be closing / reopening the app, or doing a soft reboot (via UI), now I just leave it for 30 seconds or so and it becomes responsive again.

Example a few minutes ago - approx 10:18 UTC, the music just stopped playing, and on screen it was showing ‘nothing queued’. About 30 seconds or so later, the queue was restored and I pressed play again to resume playback.

Hey @Glenn_Tesoriero,

Thanks for the update. From another fresh diagnostic report, we can see recurring Client Disconnections from the MacBook.The Roon Remote on your MacBook Pro disconnects from ROCK on a very regular cadence, roughly every 15–20 minutes throughout the day.

Each time it reconnects, RAAT also drops and has to re-establish. This is the most consistent pattern in the logs and aligns directly with your playback interruptions. The 10:18 UTC incident you mentioned is clearly visible: the client dropped and RAAT then failed to reconnect entirely.

This could be:

  • macOS App Nap or network interface sleep putting the Roon app into a low-power state
  • A network timeout setting on your Eero or switch causing idle TCP connections to be dropped
Try: System Preferences → Battery → Prevent automatic sleeping when display is off, and also disable App Nap for Roon (Get Info → Check "Prevent App Nap" in Finder). Also check if your Eero has any "client steering" or "idle timeout" settings that might be culling connections.

We’re also seeing some issues around your “Newest” Tidal playlist (1,158 tracks) is being synced constantly and obsessively; the log shows it firing dozens of times per minute, with repeated messages like Sync playlist requested, but a sync is in progress. Waiting… and fetching 1158 missing tracks

If you resync your Tidal account, do you see the same issues?

Thank you!

I’m a little confused regarding the Roon Remote disconnects on the MBP yesterday - generally I use the MBP in the mornings and maybe late afternoon, evening - throughout the day it is just in sleep mode most of the time. I’ll admit, I will often leave Roon app still open when I put MBP to sleep, but this morning when I checked, Roon app was actually not even running, so I’m surprised you were seeing frequent reconnection attempts. Is this expected even with Roon app not running?? Should I just uninstall it?? It’s a nice to have to be able to see what’s playing on the screen when I’m working on MBP, but if it’ is causing all these issues, then I will uninstall.

Also today, 2:37UTC 6/06/2026, music stopped again, and it was really difficult to get back on again. Multiple app restarts (iOS) - and I know for sure again Roon app on MBP was not running. I wasn’t able to restore playback until around 2:41UTC. As this was the behaviour I was seeing prior to opening this case, it seems the static (reserved) IPs has not really helped.

I’m not sure what would cause the constant sync - but I just initiated one at 3:43UTC, and music playback stopped and did not resume. I had to press play myself once the sync was complete.

Given that I will either close Roon App on MBP or uninstall it, if the former, will there be any benefit enabling “Prevent App Nap”?