I’m very aware of those @eaDir directories. They’ve been there as long as I have used Roon, even Roon on NAS. I just purged them recently using a script to see if those played any role (turning off indexing and/or Audio Station does not remove them) and they have not - per long term behavior - made any difference. Roon scans through all of them and ignores them VERY quickly when doing a scan of my collection. About 34 seconds to scan 210,000 files (which is a new lower number after I rebuilt the @eaDir during said recent experiment), resulting in 64643 music files. Again, this has never been an issue.
Secondly, I have a dedicated share for Roon Backups, as I always have. It is not part of the /music share. And there are no other tasks running at 4AM.
Clean up shows 0.
The reason my database is as large as it is - last time I checked, it was 10 GB - is because I have very high resolution album art for most of my files.
I hope that is of help. Please let me know if you need more.
ALSO: The performance issues I have since the latest .NET 10 release arise only when playing from long playlists and the queue gets reprocessed after each song plays…and basically each song takes longer and longer and longer to play. If I play an album rather than a playlist, performance is better. If I play no playlists, I rarely see performance degradation.
A ChatGPT analysis reported:
Yes. The logs point to a very specific cause: Roon is spending 30–40 seconds doing library/query bookkeeping between tracks, and the next track does not start until that work finishes.
This does not look primarily like a NAS read-speed problem, audio decoding problem, or endpoint buffering problem.
The smoking gun
In the current log, every noticeable between-track pause lines up with entries like:
[library] endmutation in 34453ms
[library] endmutation in 35046ms
[library] endmutation in 35122ms
[library] endmutation in 35844ms
[library] endmutation in 37587ms
Those are 34–38 second library mutations.
Examples from the current playback session:
| Track ended |
Next track started |
Delay |
Blocking work |
| “I Got the Feelin’” |
19:04:34 |
36 sec |
endmutation in 34453ms |
| “Little Latin Lupe Lu” |
19:05:28 |
37 sec |
endmutation in 35046ms |
| “Try A Little Tenderness” |
19:06:25 |
37 sec |
endmutation in 35122ms |
| “Please Please Me” |
19:07:20 |
37 sec |
endmutation in 35844ms |
| “What a Wonderful World” |
19:09:43 |
46 sec |
two long mutations, including 37587ms |
This also happened earlier on [my RoPieee], not just [my iPad]:
[my RoPieee] transitions: 36/36 had big delays, avg ~33 sec, max 67 sec
[iPad] transitions: 7/7 had big delays, avg ~38 sec, max 46 sec
So the iPad is not the root cause.
What Roon appears to be doing
Right before those long endmutation entries, the log is full of repeated lines like:
Debug: [query] Sooloos.Broker.Music.LibraryAlbum:1 dirty
Debug: [query] ... re-sorting item-by-item (internaltype=LibraryAlbum)
In plain English: after each track finishes, Roon records the play, marks a track/album/artist/work/performance as “dirty,” and then re-sorts or refreshes a lot of live library queries.
That is taking tens of seconds.
The pattern is especially suspicious because your queue is huge:
queue_items_remaining: 828
Earlier:
queue got oversized. trimming 2495 items from start
queue_items_remaining: 2495
So Roon is handling very large playlist queues while also keeping a lot of library/album query state active.
Likely practical cause
My best read is:
Large active playlist queue + live Roon library views/query state + play-count/metadata updates are causing Roon’s database/query engine to re-sort album/library data after each track, blocking the next track from starting.
This has the feel of a Roon performance bug or pathological case, not normal buffering.
The repeated line:
[updatemetadata] Flush: pending adds=2366, pending removes=57
also shows Roon has a large pending metadata-update set, though the actual 35-second waits line up most directly with the LibraryAlbum query re-sorting and endmutation entries.
What is probably not the main cause
I would not chase these first:
NAS/file read speed. Once the long library mutation finishes, Roon prebuffers and starts playback quickly. The audio engine also reports high processing speeds like HighQuality 91.6x, 27.4x, etc.
DSP/audio conversion. The logs show plenty of processing headroom.
TIDAL/Qobuz login warnings. Those appear, but they are unrelated noise.
The iPad endpoint. There are real long rtt sync iPad warnings, but the same between-track delay pattern appears on [my RoPieee] with the ADI-2 DAC. The iPad may be a separate minor issue, not the 35-second playlist gap.
[My Laptop] / localhost RAAT connection failures. Noisy, but not aligned with the repeated transition stalls.
My diagnosis
The performance slowdown is coming from Roon’s own library database/query update cycle between tracks. Each completed track causes Roon to update play history/dirty objects, then it repeatedly re-sorts live LibraryAlbum queries. With your very large playlist queues, that bookkeeping takes roughly 35 seconds per track transition, which is exactly the delay you are hearing.
The best immediate workaround is: restart Roon, close extra remotes/views/extensions, and play smaller queue chunks. If that confirms it, I would send Roon support the specific keywords:
[library] endmutation in 35000ms
Sooloos.Broker.Music.LibraryAlbum re-sorting item-by-item
queue_items_remaining 828 / 2495
[updatemetadata] Flush pending adds=2366 removes=57
That is the evidence trail.
