· The Nucleus boots up and I can connect to it in the Roon app without issue, but I have a question about configuration/storage/attached devices
Describe the issue
Still after the last update, yes it’s snappier but after “playing “ around in the Roon remote app, iPad, adding a new album and checking the queue, it was 30 tracks left music stops and the message is as always: lost audio endpoint. This is after 17 hours of use. Please fix this issue. And by the way, new Qobuz favorites are not synced to Roon even if I manually try to activate the blue script saying, syncing libraries. Looks like you have some more work to do.
We’re sorry to hear you’re having issues. We’ll need a little more action to take action on this reported symptom, however.
Your previous logs showed memory pressure accumulating in RoonServer; fortunately this had been relieved by the most recent release, from what we see in logs. However, disconnection events are still occuring with a local cause, probably in the network topology itself.
Roon logs show socket errors accumulating after a startup on 7/9. The server lost its network connection to both the local network and the internet and began retrying connections:
07/09 18:41:31 Warn: [realtime] failed to get time: Name or service not known
This never resolved until the unit was restarted.
That’s not a direct symptom of memory pressure and we don’t see any cause internal to Roon. This also wouldn’t be specific to the 218 or any Meridian protocol; these are basic TCP connection failures.
We’ve discussed your network setup before, but can you precisely describe which switches and equipment (make/model) sit between the Nucleus, the router, the 218, and the internet?
@connor here is the answer I got from @benjamin after reading my logs I also have a screen recording that shows what is happening after a loosing / returning of audio endpoint incident. How can I send it to you?
Thanks for your patience here, and for the detailed timestamps along the way, they made a real difference in pinning this down.
I went through your latest logs, and they line up with what we’ve been describing. Within a single session, memory use on the server climbs over the course of the day and stays elevated rather than settling back down. In your most recent logs it grew from a small footprint at startup to a sustained high plateau by the afternoon/evening, and only reset after a restart. That matches exactly what you’ve been seeing: smooth for a while after a reboot, then increasingly unstable until you restart again.
We can also see the connection to your Meridian dropping, and the logs tie it to that memory pressure. At the moment the zone dropped, the server was in the middle of a multi-second internal pause (memory housekeeping) while memory use was near its peak. A stall that long is enough for a networked endpoint like the 218 to time out and disconnect, which is why the drops tend to cluster later in the day once memory has built up, rather than right after a fresh restart.
So this isn’t a problem with your network or your switch setup, your wiring and topology look fine, and the Meridian is reachable. It’s the server-side memory behavior we’ve been tracking.
The good news is this is precisely what the memory-related optimizations now in Early Access are aimed at. Once you’re able to run that build, you should be able to compare directly and see whether the time-to-degradation improves. We’d genuinely appreciate hearing how it goes for you, since your endpoint and listening pattern are a useful test case.
I’ll keep this thread updated as those improvements progress toward Production. Thanks again for sticking with us on this one.
Thanks for connecting the dots with that other thread. You can attach the screen recording directly to your post here (drag and drop, or the upload icon in the reply box), or if it’s too large for the forum’s limit, a shareable link (Google Drive, Dropbox, etc.) works fine too.
Between what we found here (the DNS/network stall in your logs) and what Benjamin described in the other thread (memory pressure causing a multi-second internal pause before a drop), it’s possible both are contributing, so we’re tracking this alongside that thread rather than picking one explanation over the other.
Please keep us posted here: any further drops, the screen recording once you’re able to upload it, and especially how things look if you get a chance to try the 2.70 build Benjamin mentioned. That’ll help us narrow down which factor is doing more of the damage in your specific setup.
@vadim sorry to say but sometimes I feel there is a kind of copy / past answer method that says there is some problem with the internet from Roon.
Please explain how you can say that Roon will work without internet for 30 days but a millisecond of network dropout is the cause for loosing audio endpoint.
Fair question, and it deserves a straight answer rather than another version of the same line.
The 30-day offline tolerance is about something completely different: it’s Roon Server’s license/authorization check with our servers, an occasional background call that has a long grace period built in. It has nothing to do with the live connection between RoonServer and your 218. That connection has to carry a continuous, low-latency audio stream, so it operates on sub-second timing by necessity, not because Roon is fragile, that’s just how any real-time network audio stream works, RAAT included.
To be precise about what actually happened on 7/9: it wasn’t a millisecond blip. The log shows the network connection dropped and stayed down, unresolved, until the unit was restarted. That’s a real, sustained outage, not a flicker. Separately, what Benjamin described in the other thread is a different mechanism: a multi-second internal pause during memory cleanup, long enough on its own for a networked endpoint to time out, independent of whether your internet connection is up.
So we’re not blaming “the internet” in the vague sense you’re pushing back on. We’re looking at two specific, different failure modes (a local network-stack stall that didn’t self-recover, and a server-side memory-pressure stall), and we’re not yet certain which one is doing more damage in your case, which is exactly why we asked for the recording. I’ll go and forward it directly to the R&D team for better visibility.
Thanks for that clarification, that settles it. Since the “outage” lines up exactly with your own reboot, the network-stall theory doesn’t hold up here, that part of our read was wrong, and the memory-pressure/GC-pause mechanism Benjamin described is the one we’re going with for your case.
Given that, if you’re up for it, you’re welcome to try the 2.71 Early Access build (build 1674) now, it includes the memory and performance work aimed at exactly this: EarlyAccess: Roon 2.71 Build 1674 and ARC 1.81 Build 422 are Live!. We’d genuinely value your feedback on whether it changes the time-to-degradation you’ve been seeing. If you’d rather not deal with an Early Access build, that’s completely fine too, just wait for the general release and we’ll keep this thread updated either way.
@vadim thanks for the clarification. Always good to narrow the problems. I stick to Production and will see what happens when it happens. Hope it works out this time.
Sounds good, that’s a reasonable call. Please update this thread once you’ve had a chance to run the next production release for a while. If the drops are still happening at that point, just let us know here, or open a new thread and reference this one (ref#WN3ULF) if you’d rather start fresh. Either way we’ll pick it back up from there.
We’ve enabled some diagnostics for your account that should help us pinpoint the underlying mechanism for some of the performance problems you reported previously in this thread.
At your convenience, please simply reboot RoonServer two times and use Roon as you normally would. We’ll gather diagnostics remotely. If you encounter any performance problems or dropouts, let us know, but we’ll find them in the logs regardless.
