Roon search extremely slow - how to fix it? BUILD 1353

I think that would be an outlier case. “Let’s see, I know the band’s name started with ‘the’…” :thinking:

There was/is no need for opening a new ticket at support, as at my system is working fine. In my opinion these issues arise due to problems in Roon’s core architecture in combination with there new software architecture.
In fact, as my system is running on Audiolinux (for 6 years now) It has always been running Roon Server (iso Roon Core).
In the release notes of the latest update, it is clearly indicated that only minor bug fixes were applied for linux versions.
The only thing that changed was Roon remote. Still wondering if the origin of the problems is lying there.
If I encounter the same issues again, I am going to test Roon again with only Windows client.
Ayhow, without me doing anything, my system is running smoothly again, with Roon playing wonderrful music.
As indicated earlier, support can take deepdive in my system(logs) if that can help them to find/verify what was going on when my system became unavailable.

Search function is still very slow for me.
Roon ROCK on dedicated corei5 NUC 11th gen with 32GB RAM
Library stored on wired NAS

As long as I browse my (locally stored on a NAS) albums and select something to play, everything is more or less fine.
It’s when I do a search for an album or an artist, that the issues occur:

  • whatever is playing, stops
  • screen goes blank
  • get the blue circle in the middle ‘waiting for your roon server’
  • get the blue button down below ‘select an audio zone’
    Nothing works until the search returns come back 30-40 seconds later
2 Likes

@Patrick do I remember it correctly you are among the users with a library of 500k+ tracks?

As I have been recently showing with my live CPU-usage-per-core screenshot, it seems that performing a CPU-intense search is using up all computing power of all cores simultaneously. If this process takes longer then there is data buffered to be streamed… well, everything halts.

So far I have not read any report saying that a medium-sized library (100k or less tracks) plus a suitable machine (Nucleus+, Gen8 NUC or alike) are bringing the current roon version to the problems discussed. If I am mistaken, please write.

I am not an expert on search routines but my theory is that the current method is causing the CPU in some cases (in which cloud search is not successful?) to manually crawl all data, metadata and texts associated with your library. It that is everything related to 500k tracks, even an i5Gen11 might be coming to its limits.

@arindal, you are correct about the library size. If it is a computing power issue, the question becomes: would the most recent Core i7 with more ram fix the issue? Or is this something I have to live with until Roon finds a way to optimize searches?

Feel myself unable to answer this question. But if you decide to give it a try a would not put so much hope into just changing core level and generation as many of the recent Intel core i7/i9 running on decent frequency and low TDP are multiple-core CPUs not offering a better single-thread performance compared to your i5.

From what I know about CPU specs I would give a NUC Extreme kit a try, may it be i5, i7 or i9. These are made for extreme gaming offering suitable cooling strategies, indefinite turbo and burn more than 100W solely the CPU. Have no experience with such a machine and no idea how it works with OS and roon, although. Maybe a desktop computer with one of these Intel Cores is also a good idea.

as a data point, I restarted my roon server and waited for the database restore to complete. Search is a little bit faster in most cases, BUT: when I do a search on ‘Sinatra’, I get "Can’t connect to Roon Search - try again’over and over. If I search for other terms (say ‘Nat King Cole’) I get normal returns in a reasonable time frame and without the music cutting out etc… I have quite a bt of Sinatra in my library, as well as a Tidal subscription. Search should return something…

Exactly the same issue here. Surprised a fix hasn’t come forth (rebooting twice - one suggestion - had minimal impact … problem remains)
The search protocol/routines must have been changed as this issue is relatively recent.
To be honest, it’s annoying enough for me to question using the software - find myself using alternatives more (jplay iphone; audirvana). Shame because nothing beats the convenience of Roon (when it works!).

That’s not the point. It’s more like ‘show me all bands that chose “the” names’.
In any case, I think it is fundamentally not a good idea to exclude search terms in this way. I can already see the forum posts, ‘I started a search with “the” and nothing happens, what is wrong’ :slight_smile:

2 Likes

I have the feeling that it is search queries getting to many hits are usually causing this problem. So quite the opposite to ´should return something´.

As promised, an update on build 1366 running for some time now on my machine:

Search and the critical compiled pages such as composition lists or overall track listing got a bit slower after some days. Still fine but less snappy. All cores peak for 5-6 seconds when performing searches like ´The the´. I do subjectively feel some improvement compared to previous versions but I still consider returning to my energy routine of restarting everything daily.

What I noticed is that RAM seems to got befreed more often. Roon is for some time using more and more RAM just like before as it is active but it is far from a memory leak or runaway. After a while it ended up again almost doubling the occupied RAM compared to the moment of fresh start. That might explain why it gets slower and slower with every day. I will most probably return to a daily shutdown routine.

Throwing more CPU or more RAM to a performance issue is not going to solve the problem. It may at best provide temporary healing to current problems.

An audio streaming system is a realtime (ie need to do its tasks in a defined time frame), whereas the UI and searches are asynchronous tasks and should be scheduled appart.

My guess is that the RoonServer is too monolothic to be able to handle all the promises of Roon with their shift to fuzzy logic, which cannibalised the core streaming features.

In addition when I see some of the error logs in other threads, where recursive calls to the same function crashes the system, I also suspect programmers are not using proper programming language/frameworks.

Maybe ROON could use more CORES, if avaliable
A lot of people are using ROCK and only one CPU is working

For example, i am using a NUC8i7BEH with
Total Cores . 4.
Total Threads. 8. Max
Turbo Frequency. 4.50 GHz.
Processor Base Frequency. 2.70 GHz.

It seems that this is the case with computing-intense searches already. I have the possibility to monitor my 4 cores in realtime and saw them all peaking when one of the critical search queries was processed. Other operations such as starting a stream or compiling a list seem to rely on one core.

1 Like

I can offer one additional observation… While typing into the search box, Roon server spawns a great amount of new threads…

This is my server while playing to one endpoint. It has been restarted and all user interaction is quite snappy at the moment. Note the reported total of 129 threads…

As soon a I start typing into the search box in my iMac Roon Remote (‘Roberta’ in this case), thread count goes steeply up, nearly doubling the total thread count:

Some seconds later, this is back to normal:

With all this, I don’t experience CPU load peaks or RAM usage increases…

2 Likes

Thanks for sharing your data!

Did you try monitoring what the CPU is doing while performing one of the searches driving other user´s machines crazy like ´The the´ or ´The Beatles´?

I noticed these particular ones as well as general words like ´and´ are causing my 4 cores to peak for 2…10 seconds. It looks somehow as the CPU has to crawl zillions of texts and metadata in order to find and evaluate matches.

RAM usage is definitely not affected on a short term base neither is it peaking because of a search. I am monitoring it as I am evaluating build 1366 and RAM occupied by roon was slowly increasing over the first 2-3 days now reaching a maximum which is almost double to the starting point after fresh restart.

When you add new code (features) to already broken code, you end up with more broken code. Simple truth, and this is coming from a software architect. Roon owns it to itself and to its paying cutomers to do a maintenance release and address outstanidng major bugs, not introduce new features.
I am with @Simon_Arnold3 here, we don’t need new things while existing major features are broken, I will give examples.
@Suedkiez the fact that you do not face issues, in fact, amplifies the issues, as it seems the bugs are dependent on customer specifics, like library/data and hardware. Those are issues that Roon has to address with priority, because when you have bugs that are dependent on data, it means your code is not good, and you have to improve it.
There is no software free of bugs, it does not exist, but some Roon bugs are there for years. I am only new to Roon but here is my list:

  1. New bug from latest update - remote crashing, zones disappearing. Unacceptable bug.
  2. Volume controls bug varaince 1 - Roon is hijacking iOS volume to 100%. I have it on my iPhone.
  3. Volume controls bug varaince 2 - Roon is hijacking iOS volume to 0%. I have it on my iPad.
  4. Volume controls bug varaince 3 - Roon is hijacking volume of the playing zone to 100%, either immediatley, or by slowly scrolling to 100%, with no means to reduce the volume. Scary stuff.
  5. Using ARC crashes the Roon Server.
  6. Search, the subject of this thread, is crap. Honestly, I am one of the few that I never faced search issues. And you @Suedkiez never faced issues that I have in my system. This only ampliefies how unstable the code is, improvement is needed.

Such problems, in my honest opinion, have to have a higher priority than new features. All I see posted by Roon is “we think we have a solution or a fix, try it and see”, or “try our early access” … not good by me, it is either solved or not, there is no inbetween. If the RCA (root cause analysis) is not done, then problem is not solved.
Therefore, I think it is high time that Roon pulled all-hands-on-deck and do a maintenace release of Roon 2.0. Else Roon and we will continue like this - unbaked new features, and unfixed old features, that will co-exist in a so-so package of software.
The GOOD NEWS here is that Roon mostly works. But for a high dollar software, this is not good enough, there should not be major bugs.

One-and-a-half month response time to a broken release is not good by any book. Somehow I am not seeing the urgency from Roon that I would expect for a paid software.

My last analogy that I want to give is - imagine you have a bowl full of spaghetti, and you have a task to straighten/untangle each peice of the spaghetti. What will be easier - do the bowl first, without adding more spaghetti, or keep adding spaghetti, and straighten the old and new ones as you go.

Best regards and Happy Holidays to everyone!

6 Likes

I disagree with all of this and wrote a lengthy reply but can’t be bothered.

It’s OK. We are different people. I am holding your participation in this forum to the highest standard and dedication, and I rarely find any posts of yours that I dont’ agree with. Except this one. And this is fine by me.

3 Likes

I did right now…

Screen Shot 2023-12-16 at 4.42.12 PM

What happened is exactly what I have described in my previous post. The search took all about 3-5 seconds, and during this time and for some seconds later, the machine’s total thread count went up from 121 to 250… And during the first two seconds or so, all six CPU cores peaked, which is something I would expect to happen, with the spawning of so many new threads…

I have been observing this behavior for a long time, and this is nothing new in the most recent build. I also have never experienced dropouts on playback during this increase in thread count and the concurrent short CPU peak.

If it is of any help, and just to add a data point: in my system, I have no CPU spike nor any new threads, nor delay in any of the problematic searches mentioned in this thread - “The”, "The ", “The artist name”, “The the”, etc.
Granted, I don’t have any albums of “The The” artist in my albums, but I have 13 artist that start with “The”.