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.