This is confusing. Are you complaining that during analysis / library building, your system is slow ? Surely you realize that analysis only happens once in a blue moon, and thus complaining about system responsiveness while it’s building the database would be, put gently and politely, irrelevant ?
I’d look at database storage, specifically random read latency, which RAID-0 increases if I’m not mistaken. Someone from RoonLabs can probably let you know what to prioritize there, and if there are any gains to be made.
I used to work for a software provider and edge cases like yours were greeted with “thanks for letting us know that’s very interesting”.
Unless they were in a handful of special customers that’s as far as it went. Useful for us to know it didn’t really work in those circumstances but…
My lib is around half yours and runs on a dedicated Arch Linux server with an i5 low power quad core cpu, a Samsung M2 SSD and 16GB 2400 MHz ram. Performance is generally instantaneous/snappy (genres would be the exception, they’re aware of it and acknowledged there’s a problem but haven’t done anything about it…yet ).
a few things I’ve learned that may help you:
Roon is mostly single thread, as you point out, and would be the reason Danny suggested the fastest core speed you can muster. I imagine doubling my library would necessitate changing to that kind of CPU
there’s no benefit in running Roon’s database on a raid SSD combo. You’ll get better performance using a single SSD - I confirmed this with Roon’s CTO way back
raid0 for the tunes is also unnecessary as it only serves to increase throughout for analysis. Once that’s done the additional loading performance is of no real benefit
chunk your library into discrete drives and point Roon to each drive as a separate storage entity - this way you can chunk analysis by drive and keep the other storage areas disabled whilst one is being scanned/ analysed. I’m not sure Roon is smart enough to know 48 cores means that optimised analysis would mean concurrent analysis on each of your drives.
Another major advantage is that on startup Roon does a quick scan of the library to confirm all present and accounted for. With multiple storage areas stipulated it’ll poll them concurrently
In due course Roon on Linux will enjoy native Microsoft code that’ll further improve Roon performance and ostensibly offer the best performance over other OS’ other than Rock/Roon OS which is highly optimised for Roon.
Many thanks for your comments and recommendations.
chunk your library into discrete drives and point Roon to each drive as a separate storage entity - this way you can chunk analysis by drive and keep the other storage areas disabled whilst one is being scanned/ analysed. I’m not sure Roon is smart enough to know 48 cores means that optimised analysis would mean concurrent analysis on each of your drives. Another major advantage is that on startup Roon does a quick scan of the library to confirm all present and accounted for. With multiple storage areas stipulated it’ll poll them concurrently
I already have my music declared in “Storage” in sections in-order to improve re-scanning.
I look forward to any improvement to performance.
One thing that would be easy to implement in Roon is a user configurable scheduler for things like Audio Analysis and File Scanning, these could then be processed at a time when Roon isn’t delivering music. Then I could probably go back to using a NUC with Rock and I could save the planet a little not having to run a super computer
If it’s all pointing to the same raid array there’s no real benefit. Please post a screenshot of how you’ve defined it in Roon.
Bottom line re analysis is this:- it’s a one-off event (or at least will be when team Roon address the logic error that triggers a res) - turn it off when using the system (keeping on demand enabled if doing album listening) and let it run when you’re not using the system - it’ll take whatever it takes, but it’ll finish.
Thanks for taking the time to research those items for me, yes hindsight is a wonderful thing. At least others may benefit my mistakes. I do have another fast i7 machine I could run some tests on.
Ultimately Roon developers will make better use of modern multi-cored processors to improve it’s performance.
I’m not sure if it’s during File Scanning when new music is added or during Audio Analsis. I’ve tried so many things I really can’t remember. I’ll take better notes next time. I add files frequently and it does make an effect. Ideally I’d just like to import new content without needing to say, disable Audio Analysis (if that’s the problem), it could just be adding new files to the library. I’ll be more observant next time.
Thank you for your comments, I for one would appreciate my testing and feedback if it was my software.
Yes, all music is stored on one raid0 array in different grouped folders. These folders are then declared individually in Storage.
Don’t think that’ll deliver any benefits on a startup scan, however, to get the analysis done disable all but one storage location and let it complete, then iterate through the rest. I suspect you’ll be fine once over the initial hump of Roon ingesting and analysing. One thing to bear in mind also is that on the background Roon will be retrieving artwork, bios, reviews and tons of metadata as well as linking the lot in the background.
My experience is that the code governing Roon’s analysis process has bugs causing analysis to fall over now and again requiring that it be restarted. This is especially the case for large libraries. It is what it is, restart the analysis and it will finish.
No. Not on-demand analysis as it appears to only be used when an item hasn’t been already analysed and will in effect analyse it instantly when played anyway. Background analysis is normally set to 15-20 cores, sometime OFF. As I already said, i haven’t made conclusive notes but will do so next time I add content.
Roon uses the other cores when doing analysis, and when playing to multiple endpoint with DSP, simultaneously. In the last case, a core is dedicated for the DSP of each endpoint in simultaneous use. Otherwise, it is mostly single core oriented, so, yes, the fastest single core is the way I would go. And, I do like those 8086 processors.
Also, with libraries that large use Windows. I didn’t note in your posts which OS you were using, but, Roon recommends Windows with Mega-Libraries. Additionally, I would be using a dedicated RAID card with its own memory/processor, rather than doing any Windows OS based raid (and that includes using any motherboard RAID options).
As you indicate, during Audio Analysis, storage can impact depending on how much content you have and what the storage is, for example AA on a NAS, I’ve found, is generally going to be slower than AA on a local drive.
Maybe I should grab a new SSD and load up ROCK on my windows PC and see if MOCK will best it - of course this is not going to work or apply to everyone, but as I use my windows pc all but exclusively for Roon it certainly won’t hurt to try it. An i7-7700 in a silent chassis verses a NUC 7i7BNH should be a better proposition performance wise, especially as I run over 10 endpoints with often several streaming concurrently.
I’ve wondered if we need to segment Large into Large and Extreme in discussions. Now, that some people are posting about libraries in excess of 1 million tracks.
).
