Roon playback gets stuck with "audio file loading slowly" error (ref#5I2RNW)

“Audio file loading slowly” error at 3:45 PT today. I was playing “The Drums” by SML on the ethernet wired AirLens and it was fine for 16 minutes or so until I used the app on my MacBook to search for XTC, then the app hung up and the music stopped with that same error message playing. All devices and app controllers are binded to the main router and Volume Leveling is turned on. I feel that there has been some performance improvement, but there is still something going on.

3:57. Turned off volume leveling. Also noticed that the convolution switch was turned on - there is no file to load so it wasn’t doing anything. Anyway, turned that off too and was playing “Roundabouts” by SML (Qobuz) and searched for Steve Hackett on my MacBook and the same thing happened.

5:45 PM. Haven’t used Roon since this morning when it was working fine. Tried to run the Roon app on iPhone and on MacMini just now but it is frozen. Restarted the Nucleus

Did not play much between last post and yesterday. Worked well for the last 30 hours or so, but “audio loadling slowly” hangups between 4:45-5:00 playing Pixies’ Doolittle - DSD on the Airlens

Hey @Steve_Kerns,

Thanks for hanging in there with us on this one, we’ve been digging through the fresh diagnostic report and found something new that fits your whole history better than the Wi-Fi roaming angle alone.

In the logs from 7/2, we found the exact two incidents you described (the XTC search around 3:44 PM and the Steve Hackett search at 3:56 PM). In both cases, the sequence is identical: you browsed an artist page, which triggered a burst of image and metadata fetches, memory usage and garbage-collection pause time spiked on the Roon Server, and within seconds the AirLens, wired, not Wi-Fi, started dropping out and the stream was killed. That’s a different mechanism than the Bluesound roaming issue we’d been chasing, and it explains why the problem followed you through every network-side fix: it’s server-side resource pressure triggered by browsing, not primarily a network path issue.

We also see that this pressure builds up with server uptime. Right after a restart, GC pause time is close to 1%; by the time you’re a day or two in, it climbs to 6–8%, which lines up with your own observation that restarting fixes things for “about a day” before it comes back.

The good news: our team already has a fix for this memory/GC behavior in early access, which should make it over to the next full Production update. In the meantime, two things that should help:

  1. Try to avoid heavy artist/album browsing during active playback, especially the longer the server has been running since its last restart, that’s the specific trigger we’re seeing.

  2. Your Wi-Fi roaming fixes are still worth keeping in place. They’re real and helping (we’re not seeing dropouts escalate from the RTT spikes anymore), they just weren’t the whole picture.

Until you get a prompt to update your Server and remotes, performing a safe, daily Roon Server reboot via the webUI will also likely help you until you’re able to update. :+1:

This is great news! I installed the new version today and will let you know if I have any problems.

Hi @Steve_Kerns,

That’s great to hear. Please let us know how it goes, and we’ll be standing by for your feedback.

Well, I haven’t had the “audio file loading slowly error” since the update, but I have had a few instances when Roon freezes in the middle of a song when I am not using the app at all. For example, 4:40 PM playing “Hard Lovin’ Man” by Deep Purple it froze a minute or so in. The apps was unresponsive for a couple minutes, then I could resume play. This has happened couple times the past few days.

Hi @Steve_Kerns,

Thanks for the update! Some additional informaiton we’ll need:

  • Does this happen no matter the Roon Remote device you use?
  • Please reproduce the behavior and share the specific remote device you’re using.
Thanks, Steve! 👍

I use iPhone, iPad, and MacBook remote apps, but, as I mentioned in my most recent post, I was not using a remote app at the time of this event, and they were all unresponsive for a couple minutes.