Hi @BergeP,
Some time has passed since we last touched base on this, and we wanted to check whether you are still seeing the issue in the latest Roon release. Please let us know when you have a moment, thank you!
Hi @noris , thx for reaching back. Yes I still have loss of audio endpoint. Actually it got more frequent after the last update. Before that I could play close to 3 days + without losing audio endpoint and rebooting. After the last update I’m back to between 1 and 2 days before I have to reboot. I read on the forum that you found some memory leaks that is being fixed and also fixing some other issues. Hopefully everything settles sooner than later. I think it’s sad that we have come to this point where updates makes the system more unstable instead of better. Let’s make Roon great again. 
Hi @BergeP,
If indeed things are smooth for a day or two before performance starts to degrade until you perform a fresh server reboot, I’m quite confident the memory-related optimizations will help you.
Some of these enhancements have been released within the latest Early Access version of Roon, where we’re collecting feedback before pushing to Production, so things are moving along nicely and it shouldn’t be long before you’re able to compare performance.
Thanks for your longstanding patience here 
@benjamin I’m very curious about what you could read out of the logs I sent you regarding my audio dropouts and RAM problem.
Hey @BergeP,
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 the detailed answer. Glad to hear that everything is ok on my side and that you guys are working hard to get this resolved.
Keep up the good work and happy summer.
Petter
Hey @BergeP,
Thanks for the kind words. I’m glad we were able to confirm that everything looks good on your side, and that the work we’re doing lines up with what you’ve been seeing.
Once the next production release is out, please let us know how the experience is on your end.
Hello @BergeP ,
Since there is not much more to be said until the next release is out, we will go ahead and close this thread for the time being. If you still see the same issue after the next release, please submit a reopen support request via the technical support help form link and specify that the issue be reopened. Thank you!