Hey @BergeP,
Thanks for doing the double reboot and for your patience on this one. The extra diagnostics gave us exactly what we needed, and I have a clear answer for you now.
First, a correction. My original read in post #2, that something was reconnecting to your server thousands of times, was correct but a bit off. The pattern moved between your devices, which made it look like we’d chased a red herring. It moved because the problem isn’t in any of your devices. It’s in Roon Server.
What’s actually happening. When you open Roon on your iPhone or iPad, the app runs a small audio service that your server connects to. When iOS backgrounds the app, that service stops answering but leaves its door open, the server can knock, but nobody responds. That part is normal iOS behaviour.
What isn’t normal is our side of it. Roon Server is meant to slow down and back off when a connection keeps failing, and for most failure types it does. But in this specific case, connection accepted, then immediately dropped, the back-off never engages. Your server was re-dialling as fast as 149 times per second. Across the 29 hours of logs that’s 228,364 reconnection attempts, of which only 57 ever got an answer.
All that churn inflates the server’s memory footprint. Not because anything leaks, left idle overnight your server is rock solid, memory didn’t move more than 26 MB across four hours. But each of these episodes roughly doubles it, and past a certain point the memory cleanup starts taking multi-second pauses during which everything stops. We measured pauses of 7–11 seconds recurring every few minutes, worst case 13.7 seconds. That’s your jellyfish, and it lines up almost exactly with the 14-second stall we saw earlier.
The detail that explains a lot: those freezes continue after the reconnection storm stops, because the memory stays inflated. That’s why a reboot helps for a while and then quietly degrades, which is exactly the pattern you’ve been describing.
Your open questions:
- Were the iOS system outputs disabled remotely? No, and they’re all still showing as enabled in the logs. It is worth doing manually: on each iPhone and iPad, go to Settings → Audio and disable the “This iPhone” / “This iPad” output. Worth re-checking occasionally, as they can re-enable themselves after an app update.
- Is RAAT communication between the devices the problem? Essentially yes, but it’s the server’s handling of it, not the devices talking to each other. Nothing you’ve set up caused this.
On the endpoint dropouts, we couldn’t find them in this capture. Your Meridian 218 is completely clean across the full 29 hours: no buffer underruns, no disconnects, no failed commands. That’s good news, but it also means that if they return we’ll need a fresh log with a rough timestamp, since the cause may be separate from the freezing.
Where this goes from here. I’ve filed the full analysis with engineering. Disabling the iOS system outputs should give you real relief in the meantime, and rebooting remains a legitimate reset when things get sluggish. We’ll update this thread once I have something concrete on the fix.
