Could you please let us know whether anything changes if you reboot your Roon Server? Just to clarify, does the issue also happen when you try to play to the Mac Mini system output zone?
Please also send us the exact local date, time, and track the next time this occurs so that we can review diagnostics around that time-frame.
Yes, it happens with Mac Mini System output as well.
Ok, it happened again around 9 May 2026, 10:10am my time. I checked it is the same on the Mac mini (running one Roon Client) and on the NAS (running the Roon Server).
Song I played before it happened (Path on the RoonServer NAS):
Thanks for the update! From a fresh Roon Server diagnostic report, we can see that at the exact moment playback “starts”, the log shows:
19:05:52 [prebuffer] short read: 0 / 8820 fill=0
19:05:53 [prebuffer] short read: 0 / 8820 fill=0
This means Roon’s pre-buffer is completely empty (fill=0). The RAAT audio pipeline is being handed a stream, but there’s no audio data in it. The clock continues ticking internally (the RAAT endpoint reports PLAYING) but the position never advances because no audio frames are actually being consumed.
This is a buffer starvation condition: the server starts playback before it has filled the buffer, and then can’t fill it.
Worth noting - the stuck-at-0:00 events seem to only occur with LowQuality (AAC) files. When playback works normally (e.g., the Memory album ALAC files on May 7 afternoon), the signal path shows Enhanced or Lossless and the buffer fills to 100% immediately.
Here are some next steps to try:
1. Let audio analysis finish before playing. After a reboot/restart, wait 10–15 minutes before playing. Watch for the analysis to complete in Roon: Settings → Library → check if “Analyzing audio files” spinner is still running. Only start playback when it’s idle. This directly addresses the resource contention.
Throttle background audio analysis. In Roon: Settings → Library → Background Audio Analysis Speed → set to “Throttled” (or “Off” if you want manual control). This prevents the analysis process from competing with live playback.
Separate your Voice Memos / corrupt files from the music library. The logs show Roon repeatedly trying and failing to analyze a large number of Voice Memo .m4a files and some corrupt MP3s (e.g. the Sulari Gentill audiobook file). These cause constant analysis noise. Move or exclude those folders via Settings → Storage → Edit the watched folder → use the “Organize” or exclusion options.
Thanks for the timestamp! From a fresh Roon Server diagnostic report, we can see the log clearly shows a manual pause of the track, 10 seconds into the song. Did playback stop by itself, or did you (or a remote/app) pause it?
If it stops by itself on other occasions, the culprit is more likely to be your Roon Remote client disconnecting (as happened at 18:35:32 — the Mac at 192.168.8.199 dropped off the network), which can abort playback mid-song.
On the Mac Mini: open System Settings → Battery (or Energy Saver) → uncheck “Put hard disks to sleep when possible” and set display sleep independently from system sleep.
Also check System Settings → Network → Wi-Fi (or Ethernet) → Advanced and disable “Wake for network access” if it is causing erratic re-connections. If the Mac is on Wi-Fi, switching to Ethernet almost always fixes this class of problem.
I’d also test out temporarily disabling your macOS firewall, and see if the same issue occurs.
