Does the issue happen with local library music, streaming service music, or both?
· *Only streaming* music is affected.
Please select the streaming service(s) with which you're encountering playback problems.
· TIDAL, Qobuz
Have you tried logging out and back in again to your streaming service in Roon Settings?
· Logging out and back in had no impact, the issue remains
What are the make and model of the affected audio device(s) and the connection type?
· Not likely a device as is seen on PreSonus interface connected to Mac Studio, Apple AirPort Express, and RPis running Ropieee
Describe the issue
After updating to Roon 2.0 build 1490 on server/remote (Mac Studio w/ macOS 15.2) playback through all devices and on the Mac Studio randomly stops after some time between a few to 40 minutes.
Describe your network setup
Internet connection to Mac Studio is via Ethernet, and connections to end points are all wired Ethernet
As a first step, can you double check your Mac firewall settings to ensure Roon is listed as a proper exception? An easy test for this can be to temporarily disable your Mac firewall and see if the same issue occurs. Here’s more info:
Can you confirm that all your Roon devices stay on the same local subetnet within your network, especially during playback? Please disable other subnets temporarily to ensure all devices are functioning within the same subnet and let me know how things perform.
If you’re still running into issues after the above, we have seen users have a better experience in the past if they change their Router’s DNS servers from the ISP provided ones to Cloudflare DNS, Quad9 or Google DNS. Can you please give this a try and let me know if it helps?
Benjamin I saw this post as a response to another problem report and tried all but the DNS server and still had the random playback stop issue, before I filed my report. I also neglected to mention that several times after starting Roon there was a “RAATserver” failure popup with a lot of code, occurring several times. I rebooted the Mac Studio several times, after closing ROON, and haven’t seen the RAATserver issue in a day or so.
I’m pretty sure this is a result of either the last ROON SW update loaded yesterday or the macOS update also loaded yesterday. Unfortunately I didn’t run ROON after just doing one update too long.
I’ll try the DNS thing for grins. Also note sometimes the random stop takes as long as 40 minutes to occur so it’s hard to know for sure if the problem exists.
Hi @likeanice1903,
We’ll be on the look out for the results of trying the DNS. If the issue with playback happens again please note the date and time it occurs and let us know.
DNS changed to Cloudfare and album played that stopped playback after ~35 minutes. Time approximately 9:10 PM EST on 19 Dec. Previous stops were noted while playing playlists of selections from various albums. No further “RAATserver” exceptions.
Roon continues to stop playback randomly. In addition to other examples given previously, this also happens while listening to a radio streams and music in my library sourced from the local drive. In all cases the Roon transport || (pause) symbol reverts to > (play), same as if playback is stopped by mouse-clicking the || (Pause) icon. This is a fundamental flaw that I have to believe is in the release and needs to be corrected. Let me know if I am wrong and I am the only customer with the problem and if so, next steps.
Daniel where are you guys on this issue? This is extremely annoying. I’ve been a subscriber for at least 2-3 years and this is a fundamental problem that simply should not be happening at this point in Roon’s company history. If Roon cannot reliably playback anything from any source, what good is it?
Thanks for your patience so far, and you have my apologies for the delay!
Based on a recent diagnostic report from your Roon Server, we saw repeated indications that playback failures were caused by repeated audio dropouts, and samples are not being delivered to the DACs in time for continuous playback.
When these dropouts occurred, we saw the track buffer was only at 3%, which suggests insufficient buffering to handle audio stream interruptions. In addition, the issue occurred across multiple endpoints (Ropieee LR, EDM Studio, and RoPieee Den), suggesting a systemic issue rather than one limited to a specific device.
What happens if you increase the buffer size within the zone settings in Roon?
Do you have any additional network components that may be throttling bandwidth to your Mac studio running Roon Server? If you can simplify your network and overall setup, temporarily, this would be a helpful test.
Benjamin I appreciate that you can do some remote debugging. There is no “buffer size” parameter for any of my devices. Furthermore:
The Roon endpoint devices and network have been stable for a long time and the problem did not occur until the Mac Studio running Roon Server was updated to macOS 15.2 and/or the latest Roon SW update. Let me describe each:
a. “EDM Studio” is a PreSonus “STUDIO 26c” connected directly to a Mac Studio USB C/Thunderbolt port. I am pretty sure it has had random playback stops as the only endpoint playing (i.e. when not in a group). b. Ropieee LR and RoPieee Den are Raspberry Pis running latest RoPieee SW, both Ethernet connected to the LAN. c. Redbook_Den and Redbook_LR are both Apple AirPort Express modules, also Ethernet connected.
The Network routers are supported ASUS units less than 1 year old, the Mac Studio is also less than 1 year old.
When Roon is being used there are never any other devices on the LAN that are doing bandwidth intensive chores. In fact, the IPTV signal is separately fed from the Lumos fiber interface modem.
I could simplify the network somehow I suppose, however, having the PreSonus audio interface directly connected to the Mac Studio is as simple as it can get I assume.
The WAN is Lumos 1 GB fiber, both directions.
Are there any macOS settings that may have come to play in macOS 15.2 that could cause this?
I appreciate the troubleshooting and am surprised this apparently not a more universal problem. Please let me know next steps.
We’ve seen reports of local audio devices losing connection with Roon specifically (from the audio settings page) but not so much around audio drop outs, or at least not specifically related to the recent Sequoia update.
On that wavelength though, do you have your Mac firewall active on the server machine? What happens if you temporarily disable it - can you reproduce the issue?
And if possible, are you able to test playback from the system output of the Mac studio?
We reviewed a fresh diagnostic from your Roon Server, and didn’t see any obvious errors during playback, how have the last 24 hours been?
Thanks for the update Benjamin. Regarding your questions:
I have not used Roon much in the past 24 hours so I am not surprised that no errors were seen. Note that it can be a long amount of time between playback stops (hours mostly, but can be as short as minutes).
The Roon “Audio” settings page allows two system outputs- one plays to the Apple Display connected via Thunderbolt cable, the other is the really bad speaks in the Studio box itself. I will play a radio stream through the Studio box when I am not home and see if it happens.
In the Mac Steetings > Network > Firewall, the Firewall is active. However under Settings > Network >Firewall > Options, the “Block all incoming connections” switch is OFF, and the following Roon-related items in the list show as “Allow incoming connections” a. “RAATServer” b. “Roon” c. “RoonAppliance” d. “Tailscale” (note that I have had Tailscale active on the Mac Studio and my iPhone and last time I checked Roon ARC was working. To that point, in Mac Settings > Network > VPN also shows that Tailscale is active). Before I turn off the firewall for what could be hours long testing, can you let me know if this still makes sense since Roon-related incoming connections are allowed. Also, are there any other Roon elements that should be enabled in the list?
I recall some Roon releases back there was a problem with Apple AirPort Express modules dropping from the Audio (settings) list. That was subsequently fixed and is not an issue- all my devices are stable on that page.
Just to review exactly what happens with the Roon transport controls: At the bottom of the screen is “Previous” (with the lamp to its left indicating “Signal Path” when playing), Play/Pause, and “Next” (with the Queue button to it’s right). When this error occurs the play symbol goes to “Pause.” To restart playback, one has to click the “Pause” symbol. I don’t recall if the signal path lamp goes off but will note that in the future. So it’s not a dropout problem per se. I think I have witnessed a very few actual dropouts where playback is lost briefly, seemingly moreso with Qobuz vs. Tidal. Presumably that could be on the streaming serve end…
We’ve examined diagnostics more closely from the affected RoonServer and RAATServer instances.
Sample dropouts are accumulating as RoonServer buffers the audio stream - eventually, they accumulate in sufficient numbers to overwhelm the buffer, and you experience an automatic pause or audible interruption to playback. This occurs with every Zone, but it occurs more frequently with grouped Zones and with higher sample rates/bit depths.
Taken together, these symptoms indicate that the network path between RoonServer and the internet - and between RoonServer and your Ropiees - is experiencing either interference or issues with packet routing/managed network software.
You’ve mentioned that this Mac is connected via ethernet - have you disabled the WiFi connection, to verify that RoonServer isn’t intermittently relying on that network interface?
What hardware sits in between the Mac RoonServer and the internet? Make sure multicast forwarding and IGMP snooping are enabled in any router or firmware, particularly if there is a mesh network involved.
Please try restricting playback to 44.1KHz in your Device Setup for the System Output of the Mac and attempt to reproduce the issue. Gradually increase the sample rate and see when dropouts occur. Please share a timestamp of this event here or the name of the track that was playing when the incident occurred.
How precisely have you configured these Airport Express modules in this topology?
How many routers do you have in this configuration? We need a precise picture of your network topology to assist at this point.
This depends on the network pathway serving the Mac, and how many network interfaces are available on the Mac. I’d also verify that the MacOS itself isn’t restricting RoonServer’s network access by navigating to System Settings → Privacy & Security → Local Network and toggling on network access, if you haven’t already.
Connor the continued support from Roon is much appreciated, and I am impressed with the level of diagnostics capability seen on this problem.
I was surprised to see that WiFi access was enabled on the Mac Studio running Roon server. My guess is that the macOS 15.2 update enabled it. I recall that happening with a macOS release long ago, so I’ve made a mental note to check that with every macOS update in the future. Furthermore, I think this reversion of “WiFi enabled” caused network issues with Roon in the past.
Regarding your last point, I verified Roon has local network access.
At times in the past I have had playback issues with high sample rate material, seemingly due to source/Internet throttling, moreso with Qobuz than Tidal. In those cases, Roon often displays a message when the playback stop occurs.
I also had intermittent playback issues in the past I suspected were a result of Roon endpoints being WiFi-connected, which motivated me to run cable such that nothing “Roon” is WiFi connected.
The (ancient) AirPort Express modules are specifically configured to have their radio off, and are currently only used as Roon endpoints. However, one of them is relaying the Ethernet connection to a Ropiee via its single switch port. The AirPort Express only has a 10/100 interface. Everything else in my network is 10/1000. All cables are CAT-6. While I assume 10 Mbps should be enough for the Ropiee, could I be wrong?
I will check router multicast forwarding and IGMP snooping ASAP, and also generate a detailed block diagram of the network.
My bet is that turning off WiFi on the Mac Studio will fix this issue. Otherwise I will reduce sample rates as you suggested to troubleshoot. I will followup again soon.
