Slow database response for Discover and Overview

Core Machine (Operating system/System info/Roon build number)

QNAP 269L 3Gb Mem Roon Server Status : Running Version : 1.7 (build 571) stable
QPKG-Version : 2020-06-19 Process ID : 15812

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Ubuqiti managed network, both Wifi and Ethernet. QNAP and Major Streamers on Ethernet, Constand web performance and no errors show on connections and routing.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Multiple devices, Multiple Sonos WiFi, RME DAC USB, Linn Ethernet, Raspberry Pi Ropiee Wifi,

Description Of Issue

Speed or response from Database. Examples ‘Discover’ requests returning in 1 min 20 sec, ‘Album’ in 28 sec. Then some Artist returning in 4sec. 3 minutes later ‘discovery’ over 1 min again. Picking an album or artist from ‘Discover’ list often returns sub second. Album tracks <2 secs. However, an artist search can be 1 min pus. Occasionally, if I cancel the DB request and run again it return in 10 secs. History info return 52 Secs. across Local, Tidal and Qobuz.

Today … Discover took 1min20, Overview >20sec, Discovery on another wired machine 1min 55. Artists 4 secs, Genres 2 secs, Discover again 1min 38sec.

These all occur when QNAP @ CPU max 58% and Memory 52% max usage.

Roon playing music not interrupted. Occasional long >10sec wait on pressing play and music starting. Intermittent performance.
Happens on all zones (>10) and Multiple Controllers on Mac and IOS. Library on QNAP is 3K albums, 42k Tracks.

Is this the QNAP with an Atom CPU? And you don’t have the Roon database on SSD? If so, these two facts would explain the slow response. An Atom is underpowered for all but the smallest libraries (and Tidal and Qobuz albums get included in the album count of your library). And SSD is really a prerequisite for decent Roon database performance. See here.


How are your DNS servers set?
Google and Cloudflare are the more dependable choices.

Its a Intel Atom CPU D2701 @ 2.13Ghz and Db on SSD. Problem only started since last update which also cause the re-registering issue too.

And thanks fo the reply. I will remove the Qobuz too in the hope that reduces demand on the Db.

Hello @robert_sewell,

You should be aware that this CPU is below our Minimum Requirements for a Roon Core, and it is possible that this is a factor in the issue. Does the same behavior occur on another properly spec’d Core as well?

This is also a good suggestion if you have the default ISP ones currently in place.

@noris understand the QNAP power may cause some slow responses however the main issue of ‘discover’ taking circa 2mins to return certainly feels like it occurs since the recent QNAP update (the one where there were core re-authorisation bugs added). Sorry this is not a cheap shot but you can’t blame me for being suspicious of a poorly tested release and this issue.

So, to progress, I have removed Qobuz and cleaned the Db and amended the DNS to use google public ones.

No obvious change with album lists from sub second to 10s. Which is longer than used to be but ‘discover’ still 2mins ish. Not particularly accurate I know but, cpu cores not getting overworked etc,. So what else can be done to try and find out if it’s purely down to processor speed? I’m not sur3 I have another place to easily run the core.


Hi @robert_sewell,

Is the behavior the same if you try to temporarily use another Core or is this issue specific to the QNAP? To switch Cores:

  • Open Roon on the other PC you wish to try as the Core
  • Roon Settings -> General
  • Disconnect
  • On the “Choose your Core” screen, press “Use this PC”
  • If asked to Unauthorize, you can go ahead and do so. You are limited to one active Roon Core at a time but you are free to switch between them as often as you’d like.
  • Verify if the same behavior occurs on the different PC

Hi @noris

Thanks for the feedback. have had a quick go at this but struggling on two fronts. 1. If I download and run Core on my MacBook Pro then I get the icon but cannot seem to access to configure. 2. If I try and do a core change within the roon app it progress through he switching but I cannot seem to add the NAS Shares into it so cannot progress any further. I probably need to spend a lot more time on this which I don’t have right now but will get to it.

BTW. DNS changes appeared to make little difference but, removing QOBUS from the services ie reducing the services Discover interrogates has helped a lot. Quite useable.

With monitoring the CPU/Core usage not he NAS I can see Discover causes some cores to 100% and goes to explain why very slow at times (see image below with two discovery reqs whilst playing Flac from Local and Tidal. If I am running some DSD files or DSP processing then I can see that heavily utilising processor capacity too. Memory seems ok throughout though.

Will try changing core when I work out how to shift it properly.


1 Like

Hi @robert_sewell,

I am not sure what you are referring to with point #1, you don’t “download the Core”, you use the same Roon app to host the Core. As for adding the NAS shares, we have a great guide here that can help: Add Folders By Path

@noris Hi … Have tried switching (thanks for the guidance) to core on i7 MacBook and some five attempts have passed and one of two issues … 1. New build from scratch and then, Not all devices are seen once core switches ie Linn KDSM (wired) is not discoverable yes was available on previous core. thus tried to restore from a backup to pull in missing items, has failed 70% through the restore every time. Tried this on an alternative MacBook and same issue. Not sure where to go now as this performance challenge all came about from your recent update where introduced other issues too and have subsequently patched some.

Hi @robert_sewell,

That’s not good. Can you please send me the Roon logs from your PC you attempted to restore to? You can access logs by using these instructions.

@noris logs as requested at

1 Like

Hi @robert_sewell,

Thanks for sending those logs over. I took a look through them and I saw this:

Are you attempting to restore a Roon backup using Time Machine?

If so, this will not work. We have seen issues when trying to restore the “live database” to Roon, and Time Machine backups are not a stable way to restore, as mentioned in our Backup Documentation:

Using Other Backup Applications

Because the Roon database is frequently being updated in the background with new metadata, cover art, artist information, and more, backing up your “live” Roon database using external programs can result in corrupt backups.

We strongly recommend against using Time Machine, Crashplan, Backblaze, or other backup applications to backup your “live” Roon database.

If you would like to use any of these applications to back up Roon, set up a Scheduled Backup and tell your backup program to backup the RoonBackups folder.