Just as a comparative benchmark for you, I have about 145,000 tracks and just migrated the files to a new Debian based core and 7200 rpm storage device. My install is adding and identifying about 1000-1500 tracks per minute.
What do you think might be slowing my machine down? I have a ROCK (NUC-10 with i7 processor), 64 GB ram, and 250 GB M2 and 500 GB SSD. The music files are on a brand new Sandisk 22 TB professional (enterprise class) drive also spinning at 7200 RPM.
I did a bunch of poking around these forums recently to address a seemingly related problem. As my library size increased, Roon got less and less responsive, eventually getting to where loading the āAll Tracksā screen took a minute, and skipping a track could see a delay of 30 seconds or more. Of note to your situation, identifying/loading tracks was never as slow as you describe, and I was using hardware much slower than what youāre using. That leads me to speculate that your problem is not slow hardware. For example, I wonder if your internet connection is slowing things down in some way (speeds, VPN, ??).
My problem was definitely hardware. I moved the Roon server across three different machines, eventually fixing the issue with a newly built PC that adopted the following bits of wisdom I read in these forums and in the articles provided by Roon. Itās difficult to discern how current the following bits of wisdom are, but I relied on them, and things are finally snappy:
-
The dev work at Roon does not prioritize functionality in libraries that exceed 150k tracks. Such users are considered rare/exceptional, so the work put into compatibility with large libraries simply isnāt emphasized. I am particularly uncertain about the currency of this āwisdomā, and some posts here from the devs in the recent past seem to suggest that the 150k track line has been pushed to a higher number. However, the de-emphasis described here does seem to still apply at some high number.
-
Single-threaded performance in a CPU is more important than multi-core performance. Roon will not benefit much from more than 4 cores.
-
Large libraries that exceed the predictability of Roonās performance should be served on a Windows machine. This has some support in my experience. A linux-based OS (Audiolinux, for me, but ROCK is linux-based, as I recall) would not suffer as badly as Windows from the sluggishness that was plaguing me, but it would crash frequently. The Windows 10 server was slower, but it never crashed.
-
Roon doesnāt really benefit much from RAM exceeding 16GB.
-
Directly connected storage of the music files is recommended above network storage (NAS, for example) for large libraries. In my experience, an internal HDD was snappier in Roon performance than a USB 3 drive. It is my understanding that my experience in that regard makes no sense, given the sufficiently speedy specs of USB 3.
-
Roon (and the library file) running on a fast SSD is strongly recommended (there are several technology options that contribute to the speed of an SSD).
Thatās about it. If I missed something, Iām sure someone will chip in.
When my library reached 150k tracks, the NUC5i3RYK running either ROCK or Audiolinux started being annoying. I didnāt try Windows on it. Moving the server to a PC with an i7 from 2012 and 32GB of RAM did the trick, until I hit about 225k tracks. It became unusable at about 275k tracks. I built a PC a few weeks ago to deal with the sluggishness: Ryzen 7 7700X, 32GB DDR5, 4th Gen. NVME SSD, same HDDs for the music files, Windows 11. Problem solved, though I might go back to Windows 10 (or Audiolinux), because 11 is a janky piece of ā ā ā ā OS.
Again, the problem you describe doesnāt match up with my experience of slow hardware. For diagnostic purposes, you could install Windows 10 on your NUC and see how that goes. If that didnāt reveal a difference, I would do a deep dive into the way Roon is accessing the internet during the identification process. You might also consider checking on the temperatures of your cores during the identification process - I donāt think you can do that on ROCK, but you can on Windows. I suppose your CPU getting throttled could explain what youāre seeing, but Iām skeptical.
Good luck!
4 Likes
Thank you for this very thoughtful reply. As far as the internet connection is concerned, I have gig speed fiber-optic cable. Iāve hooked the Rock directly to the Netgear Orbi router. The speed always tests near 1 gig both up and down.
Responses here have largely been āthereās something wrong with your hardware.ā Iāve just upgraded my NUC; Iāve upgraded my file storage to a speedier drive using a faster USB connection. Still slow.
What is curious and so very frustrating is that Iāve had a large collection for years now, using my Rock server, and less than a year ago these problems started coming up. Iāve been a loyal and enthusiastic user of Roon (bought a lifetime license) ever since Logitechās Squeezebox bit the dust (and before).
If I wait for Roon to finish āaddingā and āidentifyingā (which must be taking up system resources) will responsiveness once again improve to where it always was in the past? Could there possibly be something wrong at the Roon end that (hopefully) the Roon Labs people are working on, or are they shuffling us large collection people off in favor of those who might be using Tidal or Qobuz exclusively?
Perhaps a question nobody asked, but I just tried disabling my music drives and running Tidal. As I expected, everything ran perfectly with no music files attached (other than the streaming service). I re-enabled my local drives and guess what - searching, adding, and identifying is taking place again, ever so slowly.
I canāt make decisions for you, and youāll also have to weigh up the pros and cons taking into account how much value you put on your data. But, if it were me I would start over with a fresh database. I would absolutely make sure that I had a good backup of the current DB first though.
I was thinking of doing that, and my only hesitation is the way Roon thinks my file structure for multi-disk albums are separate albums. (Each disk is in a separate subdirectory.) Iāve āmergedā hundreds of albums. Maybe it doesnāt matter all that much, since Iām not in a habit of playing an entire multi-disk album at one time.
Backing up now and I will try this unless somebody here suggests I not do so.
Assuming the network is good, I canāt think of anything else left to eliminate.
If you go RAID use 10, but you wonāt notice much if any speed improvement in Roon searches if your music is stored on a RAID set.
My music is stored on an 8 disk zfs pool configured as a stripped mirror pool, zfsā version/equivalent/most similar to but not really RAID10 (with zfs itās not really striped mirrorsā¦ itās more like distributed reads and writes, but with 8 disks it is quick). I will say that there was a noticeable speed improvement when it was first analyzing files. No improvement otherwise.
With 280,000 Iād consider ditch rock. I think (ā¦
) I recall Danny saying something along the lines of a dedicated high end PC being the better way to go with a really large library.
1 Like
Completely wild guess ??
Is your library high in āobscureā albums (define obscure).
Roon may well be finding the easy hits but then searching deeper (and slower) for more obscure matches. Certainly in my much smaller 150k library I see no such delays (99%+ IDed)
just a thought
I see you have finally made a post in the support part of the forum. I did wonder why this all wasnāt posted there in the first place.
As suggested above, in cases like this support usually suggest starting over with a fresh database (backup first of course) to see if anything you have done to the DB has impacted it in some way (excessive tagging for example is a known issue, as it seems are some folder structures).
I was wondering about this. Is it the absolute size of the library at a certain threshold that causes performance issues? Or is it the size of top-level folders? I have a larger library but I donāt experience these performance issues. Nothing fancy. I use the same windows laptop as a core I use for work all day. Itās wifi. Works with everything up to PCM 24/192 and DSD64 but I only have one DSD256 and 7 DSD128 albums so I just downsample to DSD64 for those. I use both convolution to suck out a base boom and DSP parametric equalization to put a treble lift back in that the convolution also seems to suck out.
My library though is not flat. For historical reasons it is scattered over the laptop, 7 NAS drives and Qobuz. All drives have main sub-folders of Classical, Pop, Jazz, Soundtracks, Compilations etc. and a few others. Large folders are segmented further, e.g. Classical 1, Classical 2 etc (I wasnāt clever enough to do something more sensible like Classical (A-E), Classical (F-J) etc.). Then under each subfolder is further subdivided by artist, composer, various artists etc. Whatever makes sense. The end result is that for example a pop discography of an artist might be in 8 places. It has cured me of folder browsing obviously, but I wonder if it has introduced accidently a certain parallelization into search and audio analysis? It would be nice if things were quicker but I am not aware of any excessive slowness.
I was thinking of this user, only 8 artists and 145k tracks. Caused severe issues for a Nucleus but not for an iMac.
Interesting. Thatās an extreme example of a flat folder structure. Anecdotally the OS does seem to be making a performance difference past a library size threshold.
Wow. Thatās really frustrating, dude. Iām sorry youāre having to start over on your library. I hope the devs try to reproduce your problem, including the merges, so you can at least get an understanding of the cause. Good luck!
There are a number of āobscureā albums - not overwhelming, but quite a few. If this is the problem (it wasnāt a year ago), then I would just need to wait a couple months for the system to finish āidentifyingā everything that it can, right?
Guess I just havenāt had any problems with Roon before and thought the Roon techs perused these community postsā¦
My collection has quite a few HD albums, and all of the music files are lossless (nearly all are flac). Because in the past file storage was more expensive, and drives were smaller, I have done duplicate file deletion quite a few times. Why? Because I have a number of āvarious artistā collections, and those will often have files that are duplicative. So, albums may be incomplete. Also, there are many different āvarious artist collectionsā published by different publishers, and those often duplicate files as well. This collection has taken literally decades to develop.
granted I have not spent a ton of time in the ROON info pages but I and everyone I know that uses ROON cannot recall anything from ROON stating it cannot handle certain Library structures.
Anyone have any suggestions on what file structure works best? I have Roon searching my various artist compilations (71,287 tracks) separately from the named artist tracks (214,342 tracks). The various artist compilations are organized by album name and, if multiple disk, by disk number. The named artists are organized first by artist name and under that the album name and disk number (for multi-disk sets).