Hey @Adrian_Berry,
Thanks for sticking with this, and for the update on 2.70. We’ve gone through a fresh set of server logs, and we want to reframe where this is pointing, because we think the “clock drifting out” read is actually leading us away from the real cause.
The drift is real in the logs, but it’s a symptom, not the source. Every one of those drift warnings comes attached to a huge round-trip time to the endpoint, 40 to 295 ms, where a healthy sync (like the one Harry captured) sits at well under 1 ms. RAAT calculates the clock offset from that round-trip, so when the network path stalls for a fraction of a second, the offset and “drift” numbers spike. In other words, the clock isn’t wandering off on its own, the network briefly freezes and the drift figure jumps as a result.
Here’s the part that rules out the Douk and the DAC entirely: at every stop, your server’s own local output (“Roon server”, the Douk on the NUC at 127.0.0.1) drops at the exact same instant as the networked Kitchen Pi. A Douk or DAC hanging off the Pi physically cannot drop the server’s own loopback zone. When both go down together, the disturbance is happening on the server’s side of the network, not at either endpoint. This is the same thing we saw back in June, and it’s still true on 2.70.
Two other things worth noting from the logs:
The old garbage-collection theory is now firmly off the table, memory is flat across the entire run with no growth over uptime. And the stops aren’t random. They land on fixed schedules: a network event every 12 hours at 05:27 and 17:27, which is still firing daily even after your DHCP reservations (so it isn’t lease renewal), plus a recurring event roughly every four hours at three minutes past the hour, and the nightly backups.
That fixed-timer, hits-everything-at-once behaviour is exactly what you’d expect from a scheduled task or a link-level renegotiation on the server or router, not a per-device fault. So I’d stop swapping Douks and endpoints and look here instead:
- On the NUC, disable Energy Efficient Ethernet / "green ethernet" on the network adapter. Periodic EEE link renegotiation is a very common cause of these clean, recurring blips that drop every zone simultaneously.
- Check the NUC for scheduled tasks lining up with these times:
systemctl list-timers and cron, plus any VPN with a 12-hour rekey.
- On the BT side, it's worth checking whether the 05:27 / 17:27 event coincides with a WAN re-sync or PPP re-auth, BT lines often run these on a schedule.
The single test that would make this obvious: leave a continuous ping running to both the Pi and the router, and check it after the next stop. You should see the latency spike land precisely on one of those scheduled times. That would confirm we're chasing a network event, and finally give us the single underlying cause you suspected rather than another symptom.
Thanks, Adrian, I think this is the closest we’ve gotten to the actual trigger. 
