Slow playback response during album or playlist transitions (ref#M78XKY)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Clicking Play on an album or playlist and when transitioning between tracks in either of the above items is very slow. When hitting play, often I click it more than once because it doesn't appear to respond in a reasonable period of time. Also, while playing an album or playlist, the transition between each track will show the progress bar for upwards of 30secs before playing the next track.

Tell us about your home network

· Fiber internet connection, Router is home brew model, very powerful, runs on ubuntu server, 16gb RAM, Intel Celeron Proc, multiple 2.5gb interfaces. Using a Ubiquiti Pro AP for wireless. Wi-Fi 6 Protocol within link speed to Roon Remote upwards of 865 Mbps

2

To add additional details about setup

Roon Server is running on a headless tower PC loaded with Ubuntu Desktop 24.04 LTS. This server does nothing else but serve as a Roon server.

32GB of RAM, Intel Core i7 6700K CPU 4GHZ, GB Ethernet

Roon Remote is an Asus NUC 15 running Windows 11 Pro (All latest updates installed)
Windows Defender exceptions in place for all Roon related application folders
Windows Firewall Rules in place for all Roon related processes

Intel(R) Core™ Ultra 5 225H (1.70 GHz)
32.0 GB (31.4 GB usable)

Music Library located on same Subnet running from a Synology Disk station

Ubiquiti Pro MAX 16 switch

I don’t think this issue is a hardware performance related problem on my end. The hardware in use for my Roon setup is overkill across the board

3

Hey @Chris_F123,

Thanks for the extra detail. Based on what you shared, this does not look like a hardware performance issue on your end.

Does this happen with both streaming and local content? What happens if you copy a few files directly to the local HDD, do those also have the issue? What model/manufacturer zone does this happen on, and does it impact multiple zones?

If you can also let us know the exact local time + date + track, we will enable diagnostics and there may be additional clues in diagnostics. Let us know!

4

Hello,

The issue appears to occur most often while playing playlists/albums/tracks from QoBuz or with QoBuz content mixed in. But, with that said, I have seen it occur on occasion while using music stored on the NAS on my LAN.

The issue happens on my Windows 11 Roon Remote (DAC=Benchmark DAC3 via USB) and Windows 10 Roon Bridge (DAC=Lynx Hilo via USB). The Windows 10 Bridge is connected in a different building about 100ft away but that location is still on the same Subnet as the rest of the gear in question. I use a Ubiquiti “UBB” Building to Building Bridge to link to two locations. Wireless link speed is full 1GB between both locations (The UBB is very fast point to point wireless link capable of linking two locations upwards of 1/4 mile away. My 100ft distance is a drop in the bucket in terms of its capabilities. Ping times are sub 10ms between the Roon Remote and the Roon Bridge across that link).

Oddly enough, since I’ve logged this ticket, the main issue (long delay between each track) has been less frequent to occur, but I do still see slow performance within the Roon interface in general. Just clicking “Home” for example often takes 30secs or more to load the content usually found on that page.

I wont be around for about a week after this post so if you need to close the case that is fine. I see enough posts on the Support Forum of other people reporting performance issues that I assume Roon Support is aware of it but perhaps not sure how to fix it yet.

5

Here are two specific examples of the issue occurring that you might be able to trace:

##########################

7:15am CST Fri June 12th (From Local Playlist)

Playing Sade , Mr Wrong
Skip ahead at mid point of song to
Concrete Blonde, Days and Days

multi second delay while song loads (load/progress bar seeking)

##########################

9:50am CST Sun June 14th (Roon “Daily Mix” Playlist)

After playing Lynyrd Skynyrd, Free Bird
Next Song Transition to
Credence Clearwater Revival, Fortunate Son

Long delay while new song loads (load/progress bar seeking)

6

Hello @Chris_F123

Thank you for your message. Can you please use the directions found here and send over a set of logs to our File Uploader? Once logs have been uploaded, please let us know so that we can check the server for your files, thanks!

7

Hello,

I have submitted the requested logs to the file upload link.

There is one “Parent” .zip file (named as my username) which contains child .zip files inside. The child .zips are named based on which system they came from.

As a reminder I am running the following Roon setup

Ubuntu Desktop acting as the Server (Log Source #1)

Windows 11 Pro acting as the Roon Remote/GUI Mgmt point (Log Source #2)

Windows 10 Pro acting as a Roon Bridge (No Logs gathered from here)

I did find it odd that I see logs on the Roon Remote system that would indicate it thinks it’s a server but maybe that’s normal, I don’t know.

image
image862×409 15.2 KB

8

Hey @Chris_F123,

Thanks for the fresh timestamp and logs! I traced both of your examples exactly, and they point to the same root cause, and it is not the network, not Qobuz, and not your hardware. The bottleneck is on the Roon Server itself: a database operation that holds a global lock and freezes the transport.

Event 1: Sade → Concrete Blonde:
You skipped to “Days and Days,” and the log shows it sitting at [LOADING @ 0:00] for a 20-second hang, at which point this appears and playback immediately resumes:

07:15:03 [OFFICE] ... [LOADING @ 0:00] Days and Days - Concrete Blonde
07:15:23 [library] endmutation in 20070ms
07:15:23 [OFFICE] [zoneplayer] Playing: /mnt/music/MELLOW/Concrete Blonde/Bloodletting/06 - ... Days and Days.wav

The critical detail: this track is a local WAV on your NAS.

Event 2: Free Bird → Fortunate Son :
Same signature, worse duration. Free Bird ends at 09:50:25; Fortunate Son goes to [LOADING @ 0:00] and sits there until 09:51:08, about 43 seconds, when this clears:

09:51:08 [library] endmutation in 42621ms
09:51:08 [OFFICE] ... [LOADING @ 0:00] Fortunate Son - Creedence Clearwater Revival
09:51:09 [OFFICE] [zoneplayer] Playing: ... ← audio finally starts

In both cases the delay you experienced equals, almost to the second, the duration of a [library] endmutation operation. The track is ready; the transport is simply blocked behind the database.

These are server-side database health issues, so the fixes are in that direction, roughly in order of value:

  1. Do a fresh database backup, then a clean restore from it. Roon's backup/restore cycle rewrites the database and very often clears exactly this kind of accumulated bloat and stuck mutation backlog.
  2. Check storage performance on the Roon Server itself. A 500–800 MiB database doing multi-second commits points to slow random I/O. If the Server's RoonOS/Ubuntu database lives on an HDD or a tired SATA SSD, moving the Roon database to a healthy NVMe SSD will dramatically shorten commit times. (The database location, not your music storage, is what matters here.)
  3. Look at what keeps generating the metadata backlog. The persistent 16k–17k pending adds suggests something is repeatedly marking large swaths of the library dirty, often heavy ongoing metadata grooming, a storage watcher rescanning, or identification churn. Letting the library fully settle (leave the Server running idle for a few hours and watch whether pending adds drains) will tell you if it ever catches up.

I hope this helps! :+1:

9

Hello and thanks for your reply.

A few things to mention.

Do a fresh database backup, then a clean restore from it.
The Ubuntu Roon server in use was a fresh build just a few weeks prior to me reporting the issues. I did not do any type of restore from backup when this server was built. It was a clean slate so it seems odd that the DB Health is problematic already.

Check storage performance on the Roon Server itself

Here are some disk performance results taken from the Ubuntu Roon Server using “fio”

sudo fio --name=roonlike_randread4k_iodepth1 --filename=/dev/sda --size=8G
–■■=4k --rw=randread --iodepth=1 --numjobs=1 --direct=1
–time_based --runtime=30 --group_reporting
roonlike_randread4k_iodepth1: (g=0): rw=randread, ■■=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.36
Starting 1 process
Jobs: 1 (f=1): [r(1)][100.0%][r=11.6MiB/s][r=2978 IOPS][eta 00m:00s]
roonlike_randread4k_iodepth1: (groupid=0, jobs=1): err= 0: pid=46940: Tue Jun 23 18:32:23 2026
read: IOPS=3026, BW=11.8MiB/s (12.4MB/s)(355MiB/30001msec)
clat (usec): min=33, max=2463, avg=320.11, stdev=72.30
lat (usec): min=33, max=2464, avg=320.64, stdev=72.42
clat percentiles (usec):
| 1.00th=[ 135], 5.00th=[ 176], 10.00th=[ 206], 20.00th=[ 262],
| 30.00th=[ 306], 40.00th=[ 322], 50.00th=[ 334], 60.00th=[ 338],
| 70.00th=[ 363], 80.00th=[ 392], 90.00th=[ 404], 95.00th=[ 412],
| 99.00th=[ 420], 99.50th=[ 429], 99.90th=[ 453], 99.95th=[ 457],
| 99.99th=[ 742]
bw ( KiB/s): min=11776, max=14288, per=100.00%, avg=12117.42, stdev=458.55, samples=59
iops : min= 2944, max= 3572, avg=3029.36, stdev=114.64, samples=59
lat (usec) : 50=0.01%, 100=0.10%, 250=17.80%, 500=82.07%, 750=0.02%
lat (usec) : 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%
cpu : usr=6.11%, sys=11.76%, ctx=91006, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=90791,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
READ: bw=11.8MiB/s (12.4MB/s), 11.8MiB/s-11.8MiB/s (12.4MB/s-12.4MB/s), io=355MiB (372MB), run=30001-30001msec

Disk stats (read/write):
sda: ios=90443/45, sectors=723544/600, merge=0/25, ticks=25148/20, in_queue=25169, util=85.85%

I ran these results thru ChatGPT to see what it thought of the disk performance. Below is the output from that Chat session

These results suggest your SSD will perform well for an Ubuntu server running the Roon database, with only a small caveat about rare high-latency spikes.

  • Workload match (closer to Roon behavior): You ran random 4K reads at iodepth=1, which is the important regime for database responsiveness and small metadata reads (as opposed to your earlier iodepth=32 “max pressure” test).
  • IOPS / throughput: About ~3.0k IOPS at ~11.8 MiB/s reads. For “lots of small reads,” this is a strong baseline for an SSD.
  • Latency: Average completion time is ~320 µs (0.32 ms).
    • p95 ~412 µs and p99 ~453 µs (generally great—sub‑0.5 ms in most cases).
    • There’s a tail: p99.99 ~742 µs (still < 1 ms, likely rare enough not to be user-noticeable).
  • Drive busy time: sda util ~86% during the test means the device is quite active under the synthetic workload; real Roon usage is usually far less “always at peak random I/O depth.”

How this maps to Roon on Ubuntu

Roon database operations and “app feels fast” behavior are typically sensitive to:

  1. small random read latency (your test hits this), and
  2. queueing (your iodepth=1 test corresponds to the common case where requests aren’t piling up).

With this SSD, you should expect:

  • Fast browse/library/database operations
  • No typical storage-induced playback stutter
  • Occasional slower responses are unlikely, and when they happen they’re more likely tied to CPU/Roon service/network than to the disk, given the sub‑millisecond tail you measured

Caveat: The biggest risk to Roon isn’t raw disk IOPS; it’s where the database lives (SSD vs HDD) and whether the drive is competing with other heavy workloads. If this SSD is dedicated to the Roon database and isn’t under sustained heavy write load, results like these are consistent with “snappy” behavior.

Lastly, just to mention, I have moved the Music library to a different, much faster NAS since this problem started. This other NAS is about 7x the speed of the original one I have been using for the past few years.

Using the other (faster) NAS seems to have helped and the long wait times have been reduced. But on occasion I will still see some slowness within the Roon GUI (Mostly related to the Home page trying to load its normal content) with a few incidents of the previously mentioned progress bar between tracks but those are much reduced compared to before.

I assume a new set of logs would probably be needed to see how things look now. Please let me know your thoughts…thank you

10

Hi @Chris_F123,

Thanks for the update and additional information! Based on a fresh Roon Server diagnostic report, the bottleneck is the same as before: a [library] endmutation database operation that holds a global lock and freezes the transport. The faster NAS reduced the symptom but did not touch the actual problem.

You correctly flagged that a clean DB shouldn’t be sick this fast. The logs show the churn engine: every cleanup cycle re-marks enormous swaths of the library dirty, a representative pass lists 17,367 dirty tracks, 37,453 dirty performers, 14,019 dirty performances, 11,547 dirty works, etc.

Something is continuously dirtying the entire library, so the metadata updater never reaches a settled state. The database has also already grown to ~890 MB of cumulative write volume. This is identification/metadata-grooming churn, not age or bloat from a restore.

This said, it appears NAS change was a red herring fix, helpful only because it shaved time off the local-file path. The fixes worth doing, in order:

  1. Fresh backup → clean restore. This rewrites the database and almost always clears a stuck mutation backlog and the dirty-everything churn loop. Even on a young DB this is the highest-value step, because what's wrong is the state of the DB, not its age.
  2. Find the dirty-churn source. Something is repeatedly marking the full library dirty (heavy ongoing metadata grooming, a storage watcher rescanning, or identification churn). After the restore, leave the Server running idle for a few hours and watch whether pending adds actually drains to zero and stays there. If it climbs back into the thousands on its own, the churn source is still live.
  3. Confirm the DB volume's write/commit behavior, not just reads, i.e. that the Roon database (not the music) is on healthy NVMe with no competing write load.
Thanks @Chris_F123, I’ll be curious to see how things perform after the above.
11

Hello,

On Step #1 you mention “Clean Restore”. To me, a clean restore would be a deletion of the original Source folder holding the DB and associated files and then a restore to bring it all back again. Is this what you are referring to or do you mean just a regular restore from fresh backup?

If your definition is the same as mine for a clean restore, then I assume I should be looking locally to the Ubuntu server hard drive for the location where these files live so they can be removed/deleted. If so, which directory/path should I target for deletion?

For Step #2…I haven’t the slightest idea why might be doing this churn to the local library on a fresh install of Ubuntu Desktop 24.04 LTS. I haven’t enabled/installed anything out of the ordinary or much at all for matter. This system does nothing else but sit there and host a Roon DB on a half respectable performing SSD drive.

The only thing that might be less than ordinary would be the enablement of the Real Time Kernal and installing the Chrony client to keep time in sync with my network time server.

In any case, I did a new backup and am doing a normal restore of the DB now. If you meant a deletion of the local DB Source folder type of restore (real clean) then I will need to repeat this exercise again

Thanks

12

Hello @Chris_F123,

A “clean restore” in this context means exactly what you described - delete the existing Roon database folder on the Ubuntu server first, then restore from backup. This forces Roon to rebuild the database from scratch rather than patching over the existing state.

On Linux, the Roon database lives at /var/roon/RoonServer/ (or ~/.RoonServer/ depending on your installation). Before deleting, make sure your backup is confirmed healthy, then stop the Roon Server service, delete that folder, start Roon Server again and restore from backup when prompted.

Regarding the churn source - the Real Time Kernel is worth investigating. RT kernels alter I/O scheduling priorities in ways that can interact poorly with LevelDB (which Roon uses for its database), particularly around write-back timing. This could explain why a fresh install is already showing mutation backlog behavior. If the clean restore does not settle the churn, switching back to the standard kernel would be a worthwhile test.

Please let us know how the restore goes!

13

Hello,

So I did a regular ole restore the other day and that seems to have helped.

I think we can probably close this issue out now. If for some reason the problem comes back I will perform the following next steps:

  1. clean restore
  2. If issue persists, I will Nuke the Roon server and build a new one without RT Kernel
  3. If issue persists after that, I’ll have to think about other options

Thanks for the assistance