Issue with focus & filter

The issue I have is twofold. My library is about 9000 albums, running on a NUC i5 V7 with 32GB RAM and a 250GB NVME. Local Gigabyte Network. Samsung SSD via USB3. Library fully scanned, no other processes running.

  1. Album view. Limited to my local files. Select focus composer. Takes quite long (about 30-40 seconds, sometimes even way over 1 minute) to populate the list. Wolfgang Amadeus Mozart is in that list. To avoid scrolling, I use the filter to search the list and enter “Mozart”. Roon searches for another 30-40 seconds and the says “no results”. Problem is: when I delete “Mozart” from the filter, the popup box with the composer names stays blank, the previous list does not come back. AND: when I close the popup and reopen the composer box again via “view more”, the list stays empty, despite the filter box is empty, no entry present! I assume that something seems to be cached, that does not allow the composer window to be populated, again. If I do the same in the “production” focus, no such issue.
  2. There is a major delay introduced by a filter problem, that occurs in all filters, when used together with a focus. Select any focus and let it populate. Once it’s up, write something in the filter box (except composer, see above) Try artist! You’ll notice, that the entries are first filtered by the first letter you entered. This reduced list is then filtered AGAIN by the first and the second letter, then AGAIN by the first, second and third letter and so on. The list successively gets smaller and smaller. But that takes time!!! So when you enter a name with 8 letters, you will kick off 8 searches, that are consecutively executed one after the other instead of one SINGLE search, when you have finished writing the name in the filter box. This process majorly slows down any filtering/search! If the filter would be applied only once (for example by hitting ENTER), the process would be many times faster.
  3. Last issue, that is search related: I have a few albums by pianist Alfred Brendel. One is “Mozart complete piano concertos”: 12 discs, where he plays CDs 3-12, and CDs 1 and 2 are played by other pianists. Roon properly tagged all files with the appropriate track artists and views it as ONE album from “various artists”. If I filter it with Brendel’s name in album view, then this album appears. If I am in artist view and click on his name, his artist page comes up. This very album is missing in “Albums in my library”, but strangely enough, there is one album in “Appearances in my library” from another pianist, where Brendel wrote a cadenza, but is not a performer himself on the album. Why is the “Mozart complete piano concertos” not displayed under his Artist view?

I think the problem starts right there. With 1000 albums and a Focus on local albums, it takes about 1-2 seconds for me when I populate the focus with an additional criterion.

I think everything else just follows from there. E.g., the progressive filtering is not a problem in my case because it populates nearly instantly with the results after each keystroke. (And I like the progressive filtering for this reason).

Do you experience any other performance problems?

Playback is fine, I even can play DSD512 (Roon converts to flac 352/24) via RAAT or other HiRes material without any lags.
Populating the homescreen after starting the Roon app on a MacBook Pro M1 or on an iPhone 14 Pro sometimes takes ages, sometimes is present after a few seconds. What I found out: when the homescreen is majorly delayed, then SOMETIMES in some browse tree (albums, artist etc.), there are focus-entries still present, that for sure I had deleted, before closing the app. So maybe some focus entries are visibly or even invisibly cached in the app (or on the NUC) and a long lasting search is executed without me having interacted with the app so far.

Oh, and I forgot: also population the “focus window” with the different choices like artist, composer, sample rate etc. takes quite some time (about 30 seconds)

Weird. I think you should move this to Support to let Roon staff examine your logs. (You may not yet have the option to move your thread. Let me know if you want and I can do it for you).

1 Like

@Suedkiez I would most appreciate that! Please do so. Thank you very much for your kind support!

1 Like

Done! I hope they will figure it out. (Keep in mind they are closed this Monday, which will add some additional delay to normal proceedings :slight_smile: )

2 Likes

Hi @dvdr,

Thank you for your post. Diagnostic logs do indeed show anomalies during indexing.

Can you try to remove this particular track from your library - fully deleting the file - then attempt to reproduce any of the symptoms you’ve described?

Herbert von Karajan - Ballettmusiken - Wagner - Der fliegende Holländer: Ouvertüre

1 Like

Hi @connor
Thanks for taking care of the issue.
I’ve done as advised.
This is, what I’m still experiencing

  • Any name entry in the small search box in composer’s focus produces an empty window - despite those composer’s names being presented in that very focus window. I get “no results” and a green “reset” button. If I click on it, the window stays empty and the search term does not disappear from the search box. If I manually delete the search term, the focus window stays blank, as well
  • If I then close and reopen the composer focus window, it will stay blank.
  • I have to open any other focus window, such as artist or production, and once they are populated and I close them, the composer focus window works again and gets populated.
  • So far, I have only experienced this with the composer focus.

As for my second point: this still happens. Due to my “just a” i5 V7 NUC with limited power, wait times are pretty long, anyway. So this “search while still typing” behaviour in the focus boxes kicking off multiple search rounds one after the other does not really help to speed things up. An “enter” command or just a short delay, before a search is executed, would help.

Let me share one observation, that might be related with the - let’s call it - “cacheing” behaviour of the composer focus: during this test, a lot of different focus-manipulations took place. I even rebooted the “Rock” machine to make sure, nothing stays untested.
After all these tests in album view, I closed and reopened the Roon App on my Macbook Pro M1. The focus in album view was set to “music” and “dsf”!!! A focus, I had used way earlier in the evening. How come, that after all the focus-actions for this “composer”-test I did, Roon brings back some old focus operation, that long was “overwritten” multiple times by this very test?

P.S.: I just did a test in album view with focus “music” and “artist = Brendel”. After that, I closed the Roon app and opened it again. Again, in album view, focus was “music” and “DSF”! After a few seconds without any interaction of mine, Roon app jumped to artist view by itself.
Then I deleted the very focus “music” and “DSF” and closed the app. Roon opened in Artist’s view, and when I changed to album view, “music” and “DSF” was there, again.
Strange…

Hi @dvdr,

Thank you for thoroughly testing and posting your results.

QA has passed along some additional questions to narrow down the precise cause.

When you were performing the above tests, did you have Roon open in a second remote somewhere in your environment?

As a test, try opening Roon on two remotes. Navigate to the exact same album details page on each remote (the album doesn’t matter). Do the load times differ between the two Remotes?

Now keep Roon open on a remote, and again attempt to reproduce the issues with Focus that you’ve reported above. Close Roon entirely on the second remote and repeat. Do the results change when you have Roon open in two places?

@connor
Thanks again for taking care of my issues. Bear with me for a moment, please.
As for now, I am suggesting a hardware related issue: the NUC7i5dnke with 32GB RAM and a bit “older” NVME might just be too slow for my database.

I was able to port my database (9000 albums) over to a Asus NUC13ANHi7 with a Samsung 980 Pro NVME (extremely fast write times) and 64GB Crucial DDR4 3200/CL22 RAM.

The composer issue is gone. Populating the window takes a few seconds, but no comparison to the long wait times of the NUC7i5dnke.
Trying out the “Mozart” entry problem: after a few seconds, the PopUp window goes blank, “no results” and the reset button appears, but 2 seconds later, Leopold Mozart and Wolfgang Amadeus Mozart appear. So the error message is coming in too early…
Emptying the small search box also brings back all available composers in the PopUp window.

So, would you agree, that this seems to be a processing speed issue? Maybe, if I would wait two minutes or more on the NUC7i5dnke, the reset button also would go away and “Mozart” would appear?

As for the “cacheing” the DSF focus: Maybe, this also is influenced by the processing speed. If the small NUC is too slow to do all it’s operations, when deleting the DSF focus filter, might the filter somehow still lurk in the system? With the new, fast NUC13ANHi7, this issue seems to be gone according to the first tests.

Please understand, that until now, I have been running this 9000 album database on a Raspberry Pi 4 using Minimserver and Asset UPnP - no speed issues at all, that’s why I was a bit surprised about the lag times of a supposedly much stronger NUC system. But I know, it’s apples with pears, completely different system, database, user experience - the goal of Roon

I’ll optimize my system on the new NUC now - would you still want me to do some more testing on the smaller NUC? I’d need a bit of time for that…

I have the same behavior in the search of the composer Focus, correct options appearing a bit faster, after a second while the ´no results´ is shown, would say. So I would not worry about this.

From how you describe the initial issue with 30-40 seconds of waiting after a search query, there might be a general problem with either lack of CPU power or overly complicated library structure so roon has to put enormous search load onto the core every time you focus or search anything.

How many tracks do you have in your library and how many of them qualify as classical? Do you have a lot of unidentified albums, multi-disc boxsets, classical samplers, albums with enormous number of tracks, artists assigned or alike? Or is you folder structure in any way complicated, i.e. several layers of folders, enormous numbers of tracks within one top-level folder or alike?

I had similar issues in the past with an even weaker CPU just cracking under this load of my overly complicated library. Brushing through the albums, tags and folders definitely helped roon being snappy again. With a powerful machine like your i7 Gen13 you might speed up things but to me it sounds as the CPU still gets too much of workload. An i7 Gen13 with a library of in the region of 100,000 tracks is expected to show everything almost instantly.

@Arindal Thanks for giving me things to consider!

My library holds about 150.000 files in about 9000 albums, 90% are flac files.
I chose a - I think - pretty common folder structure:
Artist - Album - File
In some cases for my classical collection (about 1700 albums / 31.000 files), I chose
Composer - Album Artist - Album - File

So, in most cases, a single folder does not contain more files than an album holds. Some Double/triple albums hold all files in one folder, but we’re talking 20-30 files per folder max., some still have the CD1 / CD2 subfolders.
I do have a few larger collections (like “Complete Beethoven”), but these then are also organized in CD-specific subfolders (aka “Symphony No. X” or “Piano Concerto Y”).
This folder structure is not majourly nestled, as you can imagine.

All files for years have been meticulously tagged with MP3Tag, but usually even in a classical case, they hold not more than conductor, orchestra, soloist(s), chorus.

I do not know, how Roon handles / accesses its database. I only have yearlong experience with Minimserver and Asset UPnP, that I programmed with extensive specific tags and browse tree options. Their database with my 150.000 files was running on an Raspberry Pi4 on a SDCard without problems and lags, so I’d say my file- and tag-structure must not have been all bad :wink:

That is a pretty huge library, I would except a CPU like your i5 to slow down noticeably but it should still be usable. The i7 Gen13 should handle it with ease.

Regarding folder structure: I am not in expert in that field but I have learned that a flatter folder structure is better (i.e. your Classical structure might have too many layers, particularly if there is an additional one for CD1, CD2, CD3 etc.) and one top-level folder should not hold too many files and subfolders (I was told 700 folders/albums maximum). Maybe it is possible to split them.

The problem with Classical samplers and big boxsets is not the folder structure but the sheer number of artists assigned, references and tracks. Roon has to literally search everything every time it compiles a page or performs a search so with the number of credits and tracks this workload is increasing exponentially. I have some boxsets (complete Karajan, Bach333 and alike) which bear 500, 1,000 or more credits and thousands of tracks. Even a handful of them is slowing down roon noticeably. Some with operas and oratorios if there are a lot of people taking part.

If you want to run a test, remove the biggest albums and sets temporarily and force roon to clean up the library. After a reboot it might show a more snappy UI.

Roon has its own rich metadata sourced from TiVo and MusicBrainz so even if your local tags are minimal it will handle boxsets with everything it has.

Regarding tagging you might want to check if your local tags are all recognized and linked correctly by roon. Open some of the big albums and check the credits. If there are ´fake artists´ like ´Mozart, composer´ or ´Richard Wagner (1813-1883)´ or ´Karajan, conductor´ having no links and no picture you can be sure that local tags are wrongly interpreted by roon. A quick text search also does this job, just search for your most favorite composers and conductors and check if they exist manyfold.

That is particularly the case if other metadata sources than MusicBrainz have been used for tagging. I for example had a lot of problems with older rips by iTunes, metadata sourced from FreeDB and SACDText.

It is incomparable as these pieces of software do not do any real-time referencing and rich link structure, they just use the tags they have referenced once in a one-dimensional way if it makes sense. Roon is literally crawling your complete database to find links and matches every time you make it show anything. Imagine it to be some kind of Wikipedia which is created instantly every time you browse for an album, an artist or a composer. The CPU workload for that is crazy if you have 150,000 tracks, particularly with Classical music.

I have a similarly powerful CPU compared to your i5 but I keep my permanently enabled library usually at under 75k tracks to have a really snappy experience. With 150k tracks and complex structure I would opt for the powerful i7 Gen13 but maybe your library structure needs some improvement to have a really snappy experience.

1 Like

By coincidence, I noticed this for myself yesterday. I think it’s because you have a lot of composers, and the filter operation takes longer to complete, but in the meantime, Roon puts up this misleading message.

Try not to click the Reset button and wait…

2 Likes

Again, thanks for all your answers and thoughts on the matter. So I think, I’ll try optimize my current system to provide a best as possible environment for Roon/Rock.

Having two systems to choose from at the moment, of course I’d settle for the faster one, the NUC13ANHi7.
With one caveat: The goal being a HighEnd music server in the livingroom, I will need to mount the mainboard into a fanless Akasa case (I know about Roon’s official stance on it!). Therefore I will have to limit TDP in the BIOS to 28W as to the recommendations of Akasa. So basically, I am stripping processing power…

  • Any thoughts, on how much processing power I’ll lose?
  • By lowering TDP, also the requirements of the PSU might be lower. Any idea, whether instead of the 19V/6A PSU, that came with the ASUS RNUC13ANHi7 I could use my Keces P8 linear PSU with 19V/4A?

Another thought to maybe optimize the system: install Ubuntu & Roon instead of Rock?
I read different opinions on that in the forum, some saying, that Ubuntu & Roon are better suited in terms of speed and power requirements, others saying, that Rock is the optimum software for a NUC. Mind jumping in with some Pros and Cons?

Thanks!

With an i7 Gen13 limiting thermal power should not be really noticeable as most of critical processes in roon defining the individual ´snappiness´ run on a single core and this CPU has plenty of cores.

I cannot tell you how it works hardware- and motherboard-wise as I have no experience with that.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.