Hey @H.Peter_Dicks,
Thanks for your patience. We were able to run through a fresh set of Roon Server logs, which were helpful. We went through the full set (about three weeks of continuous data, July 20 through August 7), and we want to share what we found, because it changes my thinking a bit from our earlier suggestion.
Every time playback stopped on your SP4000 or your iPhone, the same event was recorded, the stream was cut because the endpoint ran out of audio to play. There were 374 of these over the three weeks: 261 on the SP4000, 101 on the iPhone, and 12 on the Eversolo.
In all 374 cases the server had the track fully buffered, 100%. The music was already downloaded and sitting on the Nucleus, ready to go. It never made it across to the player.
Looking at the Nucleus’s own health statistics over the three weeks, memory usage climbs steadily, roughly 120 MB per day, and as it climbs, the server starts pausing. By day ten or twelve, RoonServer is pausing for two to nine seconds at a stretch, with a few stretches considerably longer.
A pause like that is more than enough to starve a connected player and trigger exactly the stop you’re seeing.
Two details confirm this isn’t a coincidence:
- Stops happen during pauses about three times longer than normal. Nearly 60% of the stops line up with a pause of over two seconds.
- Your Eversolo, which is wired and which you’ve said performs perfectly, shows the same underlying symptom. The logs record round-trip times to it as high as 895 milliseconds, on a wired gigabit connection, which simply isn’t physically possible from cabling. That number is the server pausing mid-measurement.
In other words, the Eversolo is experiencing the same thing; it just holds a deeper buffer, so it rides out the stalls instead of stopping. Your two portables have less headroom, so they fail first and most visibly.
Importantly, every time RoonServer restarted (July 21 and August 4 for the version updates), memory dropped straight back to normal and the pauses went away, then the climb started over.
All of this said, our latest update contains a handful of memory-related optimizations that should help directly with the above issues.
And with that, my original suggestion still holds, it’s just not the whole story.
There is one day in the logs (August 5) where the stops clearly aren’t explained by the server pausing. On that day the logs show your SP4000 becoming genuinely unreachable over the network: 53 “no route to host” errors, and repeated connection attempts that escalate and then give up entirely. On the same day, the round-trip time to your iPhone jumps from a healthy 1.8 milliseconds to 462 milliseconds within seconds.
Comparing the three endpoints, the portables are fine most of the time, their typical response times are good. It’s the occasional worst-case spikes that break playback, and those spikes are four to five times worse on the mesh-connected devices than on the wired Eversolo.
So both things are true: the Nucleus is stalling, and the mesh connection has bad moments. They compound each other, which is why your portables are hit so much harder than the Eversolo.
First, and most useful, please restart your Roon Server (Settings → General → Restart, or simply reboot the Nucleus), and then use the SP4000 and iPhone normally over the next day or two.
If playback is clean immediately after a restart and then gradually gets worse again over the following week or so, that confirms the memory optimizations we’ve released isn’t helping you.
Second, the network steps, worth doing in parallel:
- Connect the iPhone and SP4000 directly to your main Fritz!Box Wi-Fi, bypassing the Repeater 6000, and see whether the stops become less frequent.
- In your Fritz!Box, assign fixed IP addresses to the Nucleus, the Eversolo, and the SP4000. Your Eversolo is currently bouncing between two different addresses (.53 and .54), which forces Roon to rediscover it.
- Please confirm the Nucleus is wired directly to the Fritz!Box, and not going through the Powerline 1260 at any point.
Apologies for the long post, but we’d rather show you the reasoning than just hand you a list of things to try. Let me know how the restart test goes and we’ll take it from there.