Hey @Johannes,
Thanks for the timestamp. We looked for the “Cavalleria rusticana” play (Staatskapelle Berlin) around July 5 at roughly 23:00 your local time, but that moment again falls outside the logs we currently have. The server keeps only a rolling window of recent activity, and by the time the set was captured, the July 5 window had already rolled off. So we can’t trace that specific entry directly.
That short window is itself worth explaining, because it points back at the root cause. RoonServer doesn’t keep logs for a fixed number of days; it keeps a fixed number of files that roll over as they fill up. You spotted this yourself when you noted 21 logfiles being produced in the period, most generated overnight. That volume is the tell: your server is writing an unusually large amount to its logs, which burns through the whole retention buffer in about two days. What’s filling them is the storage instability we identified earlier, hundreds of “IoFailure” warnings and the repeated delete-then-undelete re-import cycles on your NAS library. In other words, the logs are short because of the underlying issue, not independently of it. As the storage churn settles, the logs will naturally cover a longer span again.
Combined with the History count swinging (dropping tens of thousands of entries, then returning), this points away from a playback problem and toward the same root cause behind the mass re-additions: your Roon library index being disrupted and rebuilt when the NAS share becomes momentarily unavailable. We can actually see one of these mount interruptions in the recent logs, where your music volume dropped and then came back, immediately followed by a burst of file re-reads and errors. When file references are lost and then resurrected like that, stale or mis-associated play records can resurface in History with a fresh “X hours ago” timestamp, which is what a phantom play could look like from your side.
Importantly, this is a share-availability problem, not a disk-health one. Your drive benchmarks being clean is fully consistent with what we’re seeing; the issue is the NAS share dropping off the network briefly, not the disks themselves. A couple of things worth checking on the NAS side:
- Whether that specific volume, or the NAS, has any sleep, hibernation, or power-saving setting that lets it spin down or drop its SMB connection when idle.
- The NAS's own system log around the times these happen, looking for SMB session resets, the volume going offline, or the network link dropping.
And the one thing that will let us catch a phantom in the act: the next time one appears, please export and upload your own manual Roon Server logs within an hour or two of noticing it. Because of the short retention we just described, that quick turnaround is the only way the relevant moment will still be in the logs when they reach us. If you can, note the exact local time you spot it, too.
Please use the directions found here and send over a set of Roon Server logs to our File Uploader
Thanks again for your patience working through this with us. 
