Windows 10 fully updated. Dual 6-core Xeons with hyper-threading. 64 GB RAM. Roon on 256 GB SSD system drive, database on 2 TB 7200 RPM SATA drive. Dual Nvidia graphics adapters (non-SLI).
Roon process in Task Manager looks like this (max CPU usage is 0.5%):
Sometimes the process drops to zero percent CPU usage and I have to kill it in Task Manager. Re-launch usually occurs pretty quickly then – about 6 -10 seconds.
1.3 has analyzed all my files including my new-to-Roon multichannel files. 1800 albums, 13,000 tracks. Slow startup occurs at system boot as well as during current session after closing and re-opening Roon.
I do mean the database. I’ve got a junction file at C:\Users\Jeff\AppData\Local\Roon that points to my big Data drive. I don’t want cache or log files filling up my system drive. I have enough application files to do that! I can put in a hard link or symbolic link instead if you think that might change Roon’s behavior.
Having the database on SSD offers huge performance gains over any spinning platter – see also the recommended specs. Also note that Roon’s logging needs are modest and rotated.
Given your system and library size, Roon should fly when on SSD.
Thanks, Rene. Here’s a screenshot of my current Roon folder size. I cleaned up my Library (but not the cache) day before yesterday. Does it seem normal? I’ve only got 25 GB out of 256 GB left on my system drive:
EDIT: Further, I can see a few seconds difference between an SSD and conventional HDD, but certainly not 5 or more minutes worth. I’m afraid something more subtle is going on, and probably user/system induced.
Database read/writes are pretty intensive. 5 minutes seems a long time indeed – especially with your system. But in any case, Roon will behave much nicer from SSD.
It looks like my database takes up 2.2 GB of the 2.45 GB that the whole folder uses. I’m estimating then about 5900 tracks per GB of database space. Reasonable? If the cache, collected album art, logs and temp folder sizes never go much over a hundred megabytes or so, then I will try putting the database back on my SSD. I’ll report back if the switch back to SSD makes any difference at all.
The performance differences between HDD and SSD for our databases are profound–at Roon’s launch in 2015, SSD was already a mature, frequently deployed technology. We built the software around it, and are deliberately taking advantage of things it can do practically that HDD’s can’t.
Some operations take 100x longer on spinning disk. That’s why we put SSD in our minimum requirements.
(90% full SSDs present a different set of performance problems, btw, especially as they age and start having to retire flash cells. Not the same as, or as bad as, HDD’s, but you can get a lot of weird, non-linear performance behavior out of them under those circumstances).
The relationship between library size + database size is not a simple ratio. Most of the data volume is related to artists and albums, not tracks, so a collection with a ton of box-sets will take up less space, and a broad collection will take up more than a collection than a deep one.
I strongly urge running moving the database to SSD as a first step, then see where things are. If you’re still seeing 5 minute boots from SSD, @support can grab some logs and try to figure out where the time is going.
I was adding new multichannel files to existing albums in my Library, because some of my special editions have 5.1 mixes that I never ripped because Roon didn’t support multichannel before 1.3. After many additions/moves here and there, I found some of my individual tracks on modified albums suddenly appeared in Roon as compositions. Like this:
I checked and re-checked – there is only one copy of “21 Guns” in the album folder.
So in an effort to fix the problem, I re-started Roon. That’s when the hang occurred. I had to kill the process in Task Manager, make sure both Roon and the RAAT Server were gone, then re-launch Roon. The restart was fast, and when I checked again, the single-track compositions were gone (like I hoped).
The spontaneous creation of single-track compositions was occurring when the database was on my HDD, but I didn’t associate them with the hanging behavior until now.
