You’re not alone experiencing delays like this in searching (sometimes substantially longer than 10 secs), I often find the same going into an album and waiting for the page to load. Once loaded, exiting that screen and then trying to reload can take even longer. Rather counterintuitive. Huge library you’re running though, what OS are you running?
@evand I’m currently running roon on Windows Server 2016 (64bit). I had the same performance issues on Windows 10 (64bit). I know that roon is much faster (instantaneous response) with smaller libraries (e.g. 5k tracks).
@dshore single core usage is probably due to “single threaded code” written by the roon team or in a library that they invoke to conduct their search. Unfortunately, that also means that it will not be trivial to solve. I’m keeping my fingers crossed that it is already being worked on or on the roadmap.
I wrote this post not to criticize the team who are doing a fantastic job improving roon all the time.
I hope that my example helps to identify an area for significant and meaningful improvement - search experience is a core capability.
[quote=“mzbe, post:4, topic:16408”]@evand I’m currently running roon on Windows Server 2016 (64bit). I had the same performance issues on Windows 10 (64bit). I know that roon is much faster (instantaneous response) with smaller libraries (e.g. 5k tracks).
[/quote]your OS should yield the best performance that Roon can deliver as it’s running dotnet whereas under Linux and OSX it’s leveraging the mono codebase.
My library is also rather large albeit not quite as ginormous as yours. Sometimes browsing is instantaneous, sometimes it isn’t.
@evand: Navigation in roon is generally snappy when browsing via genre - artist - …
Search is the one soft spot right now - unfortunately, the other users in my family prefer search over browsing, despite my best efforts to retrain them.
I used SnagIt to record the video.
while my library is a modest 143,000 tracks, I am only running Win10Pro 64bit on an i5-6500 with 16GB ram and SSD - nothing special. search times are minimal at 1-2 seconds max if that! and library is on NAS via GB ethernet…no rocket science here. CPU is running at close to 0% for everything…music is playing in one roon ready (PS Audio DS Jr Bridge II) zone
No complaints here
Audio Analysis is FAST for both immediate and background options.
i5-4690S @ 3.20GHz with 16GB ram and SSD here. At least once I’ve had to exercise restraint when tempted to toss an iPad Pro across the room due to non responsiveness. 143k tracks is not a large library where Roon is concerned.
My Roon database is 24GB, I suspect @mzbe’s database will be in the order of 34GB and yours to be ~10GB?
Most of the “database” size is in the images, which are stored as .jpgs on the filesystem in the %USERPROFILE%\AppData\Local\RoonServer\Database\Core - xxxxxxx[some ID] — images_1 folder.
The size of the “database” (.ldb) files (with the content metadata) is about 10% of the size of the images (in my case 2.3GB for broker_1.db vs. 18GB for images_1 (after compressing the images with JPEGmini to save some space - more than 5GB in my case).
I run a library of about 300k tracks and don’t get major lag. I found that the m.2 SSD made quite a bit of difference when I put the i5 NUC together. The read speed is very fast. I suspect that might improve startup; not 100% sure about ongoing use though. @brian will be able to advise.
I can’t recall the user but there was an example of striping 2xSSD on an i7 and getting good performance on a very large uber-library. Worth reading that user’s experiences.
OK…same here. Maybe we can check-in with @Brian w.r.t. preformance twaeks in 1.3 and if they specifically target the search code. I do see ~10s search from time to time.
I’m the developer at Roon working on this problem, I’m actually taking a break from writing search code to respond to this post.
The existing search code is slow because it’s very simple, it just looks at every artist/track/album/etc name in your collection in order and picks the ones that match your search. I’m working on an improved version that uses an index of all these names to avoid having to look at each one. I don’t have hard numbers to share at this point, but I expect this will make search feel “fast” even for very large libraries on modest computers.
Designing an index does everything we need it to without consuming huge amounts of memory for large libraries (remember that for 500k tracks we have probably 5 million things to search) is proving to be a difficult technical problem. Supporting the kind of wildcard searches we want (searching for “fields” should match “Strawberry Fields Forever”, for example) means I can’t use a simple index, and the complicated ones have a lot of difficult cases that all need to be rock solid before release.
I can see the light at the end of the tunnel now, and I expect this will ship with 1.3, but it has taken longer than I expected.
One thing that would help me is more test cases to run my code against. @mzbe, (or anyone else here with a particularly large library) could I get an Excel export of your artists/tracks/albums? I can send a PM with instructions on how to export what I need and upload a file someplace only Roon staff can get at it.
