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.
Play back of the song Bomboloni did not start at all! The logs must have been cobbled with the playing of another song…
Would you mind checking the logs again? I haven’t touch Roon for a few days, and now I will search in Roon for the song Bomboloni and then press play – and do nothing else on Roon until tomorrow.
Ok, timestamp for this is 18:00, 20 May 2026 local time. Bomboloni is showing teh play animation:
Thank you for running that “clean test” and providing the exact timestamp. You are absolutely right, and we do apologize for the confusion with the previous log analysis. The fresh logs from May 20 clearly show what is actually happening.
At exactly 17:59:22, when you pressed play on “Bomboloni”, the Roon Server immediately hit a buffer starvation error: Trace: [prebuffer] short read: 0 / 8820 fill=0
This means the RAAT engine prepared the audio zone and triggered the playing animation in your UI, but the server couldn’t read any actual audio data from the file. The log confirms it stayed in this “Playing @ 0:00” state with an empty buffer for over an hour until you finally hit pause at 19:08:34. There were no mid-song network drops or manual pauses beforehand.
Why is this happening?
Since we know the .m4a file is completely healthy, the root cause lies within the native Synology package. Synology’s DSM software has increasingly restricted its native support for certain proprietary codecs (including AAC). Because the native RoonServer package relies on the host OS, it’s hitting a wall when its FFmpeg decoder tries to unpack these files.
The Solution:
To bypass Synology’s OS-level codec limitations, we highly recommend migrating your Roon Core to a Docker container on your NAS. Running Roon in Docker isolates it in a proper Linux environment that includes fully functional, unrestricted FFmpeg libraries, which will resolve these playback failures for AAC/m4a files.
You can find our complete, step-by-step guide for this migration here: Installing RoonServer on Synology with Docker
Please let me know if you have any questions about the Docker setup process, or if you’d like guidance on mapping your database and music folders to the container!
Thanks @alex_h for the detailed explanation. Makes total sense. I did not know that the RoonServeer, when it runs directly in the DSM context, uses the DSM’s decoder!
So Docker should get rid of the AAC decoding problems, right?
Thanks for the link. Will try to migrate to Docker, but this will take a bit time because it is a little bit more involved. Need to find a weekend where I can do it.
Just checking in on this, have you had a chance to get through the migration and see how everything is behaving afterward? Please let us know if anything came up or if you have any updates, thanks.
Great question, and I’m glad you flagged it before getting too far in.
The short answer is that an SSD read/write cache isn’t the same as putting the docker folder on an SSD, so I wouldn’t rely on it for the Roon database.
Here’s the distinction:
A dedicated SSD volume is its own storage pool. The docker shared folder physically lives on the SSDs, so every database read and write hits flash directly. That’s the consistent performance the guide is pointing you toward.
An SSD cache sits in front of your HDD pool. The docker folder still physically lives on the spinning disks, and the cache just opportunistically holds frequently-accessed blocks. You can’t actually pin a folder onto the cache, the cache decides what to keep, and database data can get evicted when other activity competes for it. Cold reads still hit the HDDs.
Roon’s database does a lot of small, random reads and writes, which is exactly the pattern that struggles most on spinning disks. A cache might help in practice, but it isn’t guaranteed, so it’s not a substitute for an SSD volume.
The most reliable setup is to reconfigure those two SSDs as their own mirrored (RAID-1) volume instead of as cache, then place the docker shared folder on that volume. The trade-off is that you’d be giving up the cache on your HDD pool, but a mirrored SSD pair still gives you far more space than a Roon database needs, so capacity won’t be an issue.
If repurposing the SSDs isn’t practical right now, you can still run it on the cached HDD volume, just know that performance may be the thing to revisit if browsing or searching feels sluggish later. The guide’s “Performance is poor” section points back to exactly this: the database shouldn’t live on a spinning disk.
