· For the past several months, Roon has been getting stuck when playing a song. I then get a message saying something like "an audio file is loading slowly" and the track is skipped and the next track is loaded (most often, but not always, the next track plays). Sometimes, when it is in this state, music will pause, get jumpy for a couple seconds, then continue . This occurs on my ethernet connected device (PS Audio Airlens) as well as my 3 WiFi connected BlueSound devices. Some DSP is used, with volume limiting being common to all devices and the Airlens also using EQ and upsampling functions (so far, I don't believe DSP is the culprit, but I need to do more testing). I have a Roon Nucleus Rev A that I upgraded from 4G to 8G RAM in hopes of resolving this issue, but the problem persists. Music gets stuck like this from both Qobuz and files stored on the Nucleus' internal drive, and all types of resolution (44/16, 96/24, DSD, etc...) are effected. All Roon software appears to be the most recent versions. Network router is an ASUS ZenWIFI AX with updated firmware. I believe my database (65K tracks) backup file is about 4 G, but I would rather not create a new database since I have quite a bit of metadata that I have added. Rebooting the server software temporarily fixes the problem for about a day, but the problem eventually returns after I try to use the Roon app for basic functions (searching, accessing time remaining on a play queue, etc...). Help!
Hey @Steve_Kerns, welcome to the community, and thanks for the detailed rundown.
The fact that this shows up across Qobuz, local storage, multiple endpoints, and different sample rates points us away from a single track or device issue and more toward the Roon Server, the network path, or something in the DSP/load on the server side.
To get a clearer picture, a few things would help:
Is the Nucleus wired directly to the ASUS ZenWiFi AX, or is there a switch in between?
When the problem starts, does it affect all zones at once, or just one playing zone while the others continue normally?
Can you temporarily disable DSP on one zone, leave the rest unchanged, and see whether the behavior still appears?
In parallel, we should get diagnostics around one of these events. We will enable diagnostics on your account, and the next time it happens, please note the exact local time, date, and what track was playing, then reply here so we can review the server activity around that window.
If you’d like, we can also look at the RoonOS WebUI and the Nucleus status together once we have that timing.
I have connected the Nucleus directly to the router as well as to a network switch and the problem exists with both connections. Currently, it is connected directly to the router. I haven’t tested whether all zones are effected at once, but I will the next time playback gets interrupted. After the next interruption and reset, I will disable one of the device’s DSP and see what happens. I’ll let you know the date, time, track info when the next interruption occurs so you can perform diagnostics.
1:29 PM Pacific Time on June 16th I received the “audio loading slowly” message again after I checked the play queue from the Roon app on the iPhone about 2/3 of the way through the song. The piece was “Gone…Beyond” from “Wachuma’s Wave” by Bryon Metcalf, Mark Seelig and Steve Roach on Qobuz and was playing through my ethernet connected AirLens. I tried to replay the piece, but I got the message again after a few seconds. I tried playing on one of the BlueSound devices, but the app was unresponsive for a few minutes. Now, eight minutes later, both the AirLens and BlueSound devices appear to be behaving. If the past repeats itself, plays of upcoming tracks will be interrupted until I reset the software. I will update in an hour or so
At 1:50 I used the iPhone app to click on “Steve Roach” to get more information about the artist, then playback stopped and the app was unresponsive - both the ethernet connected AirLens and the WiFi BlueSound were effected. I needed to leave, so I left it in that state. I have just restarted the server software and Roon is behaving normally.
Issues again today at 2:01 PT playing Charlie Haden & Pat Metheny on Qobuz and at 4:33 playing Flower Kings’ Blessing of a Smile. Ethernet and WiFI both stopped playing and started playing the next track after a couple minutes
I found both events you reported, and they have an identical signature.
2:01 PM PT (Charlie Haden / Pat Metheny, Qobuz, AirLens): The track “Precious Jewel (Instrumental)” was playing fine at full buffer, then at 14:01:22 the AirLens started reporting a rapid burst of Dropout messages. Four seconds later the server gave up:
14:01:26 Warn: [AirLens] Too many dropouts (>3s dropped out in the last 30s). Killing stream
14:01:26 Warn: [zone AirLens] Track Stopped Due to Slow Media
14:01:26 OnPlayFeedback StoppedEndOfMediaUnnatural
It then sat in LOADING for about two minutes before resuming on the next track, exactly the “stopped, then started the next track after a couple minutes” behavior you described. The same thing repeated at 14:04:06.
4:33 PM PT (Flower Kings, “Blessing of a Smile”): Same Too many dropouts → Killing stream → Slow Media sequence on the AirLens.
The “audio file is loading slowly” message is misleading. In every case the buffer was at 100% when the dropouts hit. The audio data was already downloaded from Qobuz and sitting on the Nucleus. The breakdown is happening after that, on the RAAT delivery path from the Nucleus to your players over your LAN/Wi-Fi. Supporting evidence:
The dropouts come from the endpoints (PS Audio AirLens @ 192.168.50.172 and Bluesound PULSE FLEX 2i @ 192.168.50.9), reporting that they ran out of audio to play despite the server having a full buffer.
It hits both your wired AirLens and a Wi-Fi Bluesound, so it's not one device or one cable.
It also reproduces on local files and Qobuz, at all resolutions, which rules out a single track or source.
The dropouts cluster into tight bursts at specific moments rather than being constant, the hallmark of intermittent network congestion or a delivery-path hiccup, not steady insufficient bandwidth.
What I'd suggest testing next, since this points at the server's RAAT delivery rather than Qobuz, in rough priority order:
The ASUS ZenWiFi AX is the prime suspect. These mesh systems are a recurring cause of exactly this dropout pattern in Roon. Two things to check: turn off any "smart"/QoS/adaptive-QoS, AiProtection, bufferbloat or traffic-analysis features (they throttle the steady RAAT stream), and confirm the AirLens and Nucleus aren't being forced through the mesh backhaul. Disabling IGMP snooping / proxy if enabled is also worth trying.
Note that "the next interruption affects all zones." Your earlier posts and these logs show the whole RAAT layer stumbling, not one zone, that's more consistent with the server/network path than with any endpoint.
Test with all DSP off on the AirLens for a session. The logs show heavy upsampling. DSP doesn't look like the cause given the full buffers, but ruling it out cleanly removes a variable, and it would lower the sustained data rate to the endpoint.
Thank you for taking a look. Adaptive QoS, traffic analysis, and ethernet backhaul mode are all disabled (and they have never been enabled). IGMP Snooping is currently enabled on both 5G bands and the single 2.4 G band, but I will disable and see if that changes anything. I will also turn off all DSP except for volume limiting and see if that makes a difference.
…and how does one ensure that the Airlens and Nucleus are not being forced through the mesh backhaul? I thought the backhaul was on the 2nd 5G wireless band and the Nucleus and Airlens are both ethernet connected.
Thanks for the reply! We were able to take another look at a fresh diagnostic report from your Server, and can now see the evidence points overwhelmingly at one specific endpoint: the Bluesound PULSE FLEX 2i, and the Wi‑Fi link to it, not your Roon Server/Nucleus, and not the AirLens.
The problem is specific to the Bluesound’s network connection, not a system-wide RAAT failure. When the AirLens appeared to fail in your reports, it’s worth checking whether you had it grouped with the Bluesound, in a grouped zone, the worst-syncing endpoint drags the whole group down, so a sick Bluesound will stall a perfectly healthy wired AirLens playing alongside it. I couldn’t find an explicit grouping record in these logs, but the pattern (AirLens never failing alone, failing only in “Upstairs”-related windows) fits that mechanism.
So the most productive things to test, in order:
Isolate the Bluesound. Play only the AirLens, ungrouped, for a full day with the Bluesound zones stopped. Based on these logs, I'd expect the dropouts to disappear entirely.
Fix the PULSE FLEX 2i's Wi‑Fi path. The latency spikes are classic Wi‑Fi congestion/roaming behavior. Options: move it to a less congested channel, relocate it closer to a node, or, best test, temporarily wire it via Ethernet and see if the long-rtt warnings vanish. On a ZenWiFi AX mesh, also check that the PULSE FLEX isn't bouncing between the main unit and a satellite (band-steering/roaming can cause exactly these RTT spikes); pinning it to one band or one node often resolves it.
IGMP snooping, you said you'd disable it; worth doing, since RAAT clock sync is timing-sensitive and misbehaving IGMP can disrupt it. But I'd rank it below the two above.
I have not had any of these zones grouped for a long time, however, it is possible it is bouncing between the main unit and the satellite. I will investigate how to pin it to one or the other.
After disabling IGMP Snooping and removing DSP (except for volume limiting) two days ago, I had no problems until playing “Supper’s Ready” on Steve Hackett’s “Foxtrot at 50” last night, but this was an “unable to load error” rather than “audio file is loading slowly” so this may be the Qobuz problem that has been discussed widely on this forum. However, this track played fine this morning.
I also want to reiterate that when this problem has occurred in the past, it was after I used the Roon app (Mac, iPad, iPhone) to search for an artist, checking play queue, etc… Even when playback is fine, these app functions are sluggish. Is it possible that there is an issue with switching between the main router and the satellite could be causing problems?
Thanks for the update. I can now see both incidents in the fresh logs and can confirm they are two separate problems — which is actually good news.
The “unable to load” on Supper’s Ready (the one you said played fine the next morning) is confirmed as a Qobuz CDN issue, not the dropout problem. Qobuz’s Akamai CDN timed out three times in a row on that specific track at that specific hour, with your download speed dropping below the minimum threshold needed to stream 24/96. This is an intermittent Qobuz-side failure and completely unrelated to the Bluesound. Nothing to fix on your end; it self-resolved, and that’s expected behavior for CDN hiccups.
The ongoing dropout problem is still active in these logs — most recently June 24 at 8:26 AM PT, during Supper’s Ready playing on your Upstairs zone (Bluesound PULSE FLEX 2i). The RTT spiked to 654ms right before the cascade, which is the same signature we saw before. Disabling IGMP snooping has not resolved it.
To your question about roaming between the main ZenWiFi unit and the satellite: yes, that is almost certainly what’s driving the Upstairs zone failures. The RTT spike profile (jumping from a normal ~5ms to 300–654ms in a single measurement interval) is exactly what happens when a Wi-Fi device disconnects from one mesh node and reconnects to another. During that association window the RAAT audio stream starves and the dropout cascade begins. It also explains the sluggish app response at those moments — the server is in recovery mode handling the failed stream.
The AirLens continues to be completely clean — zero dropout or RTT warnings in any of these logs, consistent with it being wired.
The next concrete step: force the Bluesound PULSE FLEX 2i onto a single mesh node and keep it there. On the ZenWiFi AX the most reliable options are:
Move the Bluesound close enough to one specific node and connect it to that node’s dedicated 5 GHz band (not the unified mesh SSID) — this prevents the router from handing it off to the satellite.
Or, as the cleanest diagnostic test: wire the PULSE FLEX 2i via Ethernet temporarily. If the dropouts disappear immediately, that confirms Wi-Fi roaming as the cause and tells you the permanent fix is either a wired connection or a dedicated Wi-Fi path for that endpoint.
I pinned the Node to the main router last evening. Issues last night around 7:20 and again this morning at 7:15. This time it was the endpoints were unresponsive to the iPhone app for a few minutes. Could this be due to having the app open on my iPhone, then the phone switching between the main router and the satellite?
…and “audio file loading slowly” error happened again this morning on the Node (which does have DSP turned on that I used for headphones). The Node is connected to the main router and the iPhone is connected to the satellite. I also noticed that the iPhone could not find the Node device for several minutes. I’m wondering if I should pin the iPhone to the main router?
9:45 AM Update. All BlueSound devices blocked and Apple app devices (iPad, iPhone, MacMini, MacBook) from roaming and are pinned to the router. This should keep all Roon activity locked onto the main router and prevent any switching to the satellite. Roon Nucleus rebooted and everything working well at the moment.
Thanks for the reply! We were able to review another Roon Server diagnostic report, and it seems your instincts may be correct, and the logs support it. What you’re seeing in these two incidents is essentially two separate roaming problems on the same mesh:
The audio dropouts are the wireless endpoints (Bluesound PULSE FLEX / Node) roaming between the main ZenWiFi unit and the satellite, starving the RAAT stream
The app unresponsiveness is your iPhone doing the same thing. When the phone hands off between the main router and the satellite (or its connection just degrades), it loses its control connection to the Roon Server, the server kills the stale connection after 10 seconds, and the app appears frozen until it re-associates. Having the app open and active makes this very visible because it's constantly trying to talk to the server.
One important nuance on what you tried: you pinned the Node to the main router last evening, but the morning's audio dropout was on the Node with DSP on, and the Node's Bluesound still threw 175–466 ms RTT spikes, so either the pin didn't take, or the Node is still roaming/congested even on the main unit. And the app problem is independent of that pin entirely, because it's the phone roaming, not the endpoint.
Pinning the iPhone to the main router is a reasonable diagnostic, but phones are the hardest device to keep pinned (iOS aggressively manages Wi-Fi and rotates MAC addresses). More reliable tests, roughly in order:
Disable "Private Wi-Fi Address" for your network on the iPhone (Settings → Wi-Fi → your network → Private Wi-Fi Address off). A rotating MAC makes mesh roaming and any per-device pinning unreliable, and it can also confuse Roon's device tracking.
Toggle the iPhone to a single band / disable smart-connect band-steering for it if your ZenWiFi lets you, the same way you're trying to pin the Node.
The deeper fix is the same one already on the table: this ZenWiFi AX mesh is roaming devices (endpoints and your phone) too aggressively. If wiring the PULSE FLEX confirms the endpoint half, you're left with a phone-roaming problem that's best solved at the router (per-device band pinning, or reducing how eagerly it steers between nodes).
Oops - I meant to say last evening that I pinned the Pulse (“Upstairs”) to the main router, not the Node. The Node was pinned this morning just prior to the 9:45 updated. I will run with my current configuration for a while, then explore your iPhone suggestions.
You are right - the iOS devices are ignoring the Roaming Block List on the router. I looked at disabling the private wifi address, but the iPhone warns me that this would “Allow this device to be tracked by WiFi networks and nearby WiFi devices”, so I am leery of taking that step. I am going to trying binding the iPhone to the main router.
Over the weekend, I discovered that the BlueSound devices were ignoring the Roaming Block list as well, so they are now directly binded to the main router along with all IOS and Mac controllers. Everything has been playing fine, though there have been times when app responsiveness has bee sluggish. This morning, though, at 7:45 PT, I received an “audio file loading slowly” message when playing Christian Scott’s “Phases” from a file on my Nucleus on my BlueSound Node. Is there a chance the Node lost connection from the router?