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

Me neither…

The sudden increase in threads doesn’t occur if I speedily type a search term and click Return… it is triggered by the contextual search (?, don’t remember how this type of search is correctly called), which displays results under the search box… I have observed this many times and it is easy enough to reproduce, and find it surprising… can’t think of anything that would justify such rather costly behavior, but I won’t speculate and let the observation stand on its own.

For the sake of context, this happens on Ubuntu 22.04 server, and I’ve at times wondered if this happens too for users running Roon server on Windows or Mac OS.

What do you mean by speedily type? I did not click return, just typed The The and waited, all in all about a second for results in the search window to appear. If I type The The and hit return, then it takes a bit more for me, like 4-5 seconds…

This is the result of hitting enter:

Type a search term and click return, before the contextual search gets triggered… With the contextual search, the thread peak invariably occurs.

By the way, you can follow part of what is happening in the server log:

12/16 18:45:29 Info: UnifiedAutocomplete
12/16 18:45:29 Info:     ProfileId=63:1:
12/16 18:45:29 Info:     Terms=The 
12/16 18:45:29 Info:     MaxCount=8
12/16 18:45:29 Info:     IncludeHidden=True
12/16 18:45:29 Info:     CancelKey=68847c6d22f64ab281dbacc53739d6f8
12/16 18:45:29 Info:     RequestTimeoutInMs=8000
12/16 18:45:29 Info: UnifiedAutocomplete
12/16 18:45:29 Info:     ProfileId=63:1:
12/16 18:45:29 Info:     Terms=The T
12/16 18:45:29 Info:     MaxCount=8
12/16 18:45:29 Info:     IncludeHidden=True
12/16 18:45:29 Info:     CancelKey=57fc9418577b48da8b6868f7fbf81db9
12/16 18:45:29 Info:     RequestTimeoutInMs=8000
12/16 18:45:29 Info: UnifiedAutocomplete
12/16 18:45:29 Info:     ProfileId=63:1:
12/16 18:45:29 Info:     Terms=The Th
12/16 18:45:29 Info:     MaxCount=8
12/16 18:45:29 Info:     IncludeHidden=True
12/16 18:45:29 Info:     CancelKey=49f127be37204d8c8858c48c2d435626
12/16 18:45:29 Info:     RequestTimeoutInMs=8000
12/16 18:45:29 Info: UnifiedAutocomplete
12/16 18:45:29 Info:     ProfileId=63:1:
12/16 18:45:29 Info:     Terms=The The
12/16 18:45:29 Info:     MaxCount=8
12/16 18:45:29 Info:     IncludeHidden=True
12/16 18:45:29 Info:     CancelKey=97104813013a4db88a0f357469c14a1a
12/16 18:45:29 Info:     RequestTimeoutInMs=8000

OK got it, and tried it. With contextual search, I can see a spike in thread count by 100-150… my Roon Server is on a Mac Intel i-7.

That matches with my observation…

But this is a bit confusing for me… I thought Roon got rid of local/offline search, in place for cloud based search, i.e. why are we seeing load to local system? Isn’t our library (of some sorts) uploaded to Roon cloud, and searched in the cloud compute?

1 Like

No user really knows any detail about search implementation, nor implementation details about any other functional area of Roon for that matter… So I won’t speculate on this… I just will say that I am wondering if spawning up to 150 threads on OS level isn’t a rather costly approach, and if this is intentional, ‘collateral damage’ or a bug…

1 Like

I prefer a good system to a buggy system with ARC and other features.

ROON is for listening music to relax.

Now ROON is not relaxing at all

Make a version without ARC which is working stable and without issues.

Afterwards new features can be implemented

6 Likes

I sincerely hope they are working on all these issues, but I would not of so far to blame roon as a software company for everything. For a simple reason: I have the impression that for most users roon works as it is intended without major flaws, crashes or alike. For some it does not, but that might be due to the sheer variety of configurations and systems running roon. It is said to be well over 300,000 and no two configurations are the same in terms of core, remote, network gear, internet connection and endpoints.

When you were coming up with spaghetti analogy I was more thinking of well-known electric vehicles: Imagine Tesla customer service would get complaints from Europe:

  1. ´my battery is not charging properly and loosing capacity in -30 deg centigrade´ writes a guy from northern Norway
  2. ´my autopilot is not working properly when I am overtaking at 275 kmph´ writes a guy from Germany.

Replies: ´we tested all systems, no fault here in sunny California at +25deg and general speed limit of 65mph´

breaking it down to music software, I do believe roon guys have tested everything to the very last bit before releasing a new version. For the majority of users everything works properly and they enjoy it. Among the 100s of 1,000s of users there are some who run roon in an environment or under circumstances causing problems. When you dig deeper, there is a high chance one of the following points is true:

  1. Underpowered CPU without user ever noticing it as roon ´just ran fine´ before the last update
  2. large library well above 250k tracks, unorganized folder hierarchy or well beyond the capacity of the CPU/RAM used
  3. unstable or unresponsive internet connection

I was one of them until earlier this year having all 3 problems at once being unaware of them, but noticing similar performance issues to the current slow search and Roon stuttering. Somewhen in February or March of this year there was one update which brought my system to collapse. So I did the following:

  1. bought a new server with more powerful CPU (which was not an easy choice as I wanted to stay with Qnap and HDDs)
  2. got enough of RAM and cut down my core library to under 70k tracks migrating and disabling the additional folders holding an additional 100,000+ tracks
  3. switched to fibre internet

Know what? Everything worked smooth, snappy and fine again. Okay, search got a bit slow with 1353/1354 update but nothing critical but it resumed being fast.

I have Mac with:

  1. Intel i-7 3.2GHz
  2. 32GB RAM, 1TB internal SSD
  3. Fibre optics internet with 300Mbps speed up and down.

My iOS devices are not old - iPhone 13Pro and iPad Pro with M1 chip.

My library is only 11K tracks, all local files.

Yet, I have some bugs that are over 2 years old, based on forum posts, as well as brand new bugs with latest update.

1 Like

Unfortunately this type of post is inevitable when customer support is run on the same platform as the discussion forum.
The tl;dr is ‘throw more horsepower at it’. Happens again and again and again on here. Not to pick on you specifically, but it’s so tiresome.

If that really is the solution to adequate search performance, then the underlying architecture is incredibly poorly coded and there should be reworked from the ground up.

As for this…wow

2 Likes

Figured this was a bit strange as Roon always claimed a “single threaded process” for core (pun intended) processing, everything but the analysis basically.

Had to give this a shot on my regular Roon Server:


The peaks circled are cpu usage when executing a search for “The The”, so this seem to really exercise the CPU. No wonder it brings older CPU’s to their knees!

My CPU is showing exactly the same behavior when executing one of these computing-intense text searches. As it is less powerful than your 11i5 all cores tend to peak for seconds but always return a result. Other intense procedures such as starting a stream or compiling a composition or track list seem to use mainly one core.

1 Like

Whilst accepting that these peaks in task manager represent a significant ‘increase’ in processing during the Roon search, I would not say that the processor is in anyway stressed by that activity. Not one of the cores is running at 100% and many of them are below 20% utilisation.

By contrast, in a non-Roon related activity, I can definitely stress my laptop PC:

I wouldn’t want this laptop PC to be in any way involved as either a core/server or endpoint whilst this activity was going on!

1 Like

You might have got me wrong. I am far from recommending to throw more horsepower at a specific problem. But I am pointing to the fact that many people (like myself) have been starting this roon adventure with underpowered CPU, not enough RAM and unreliable internet (via cable TV in my case), eventually piling up albums and albums founding a library that is simply to large or to complex for the given system.

So it is not about ´throw more horsepowers´ but ´try to meet the basic specifications given in roon´s 2018 blog posts and keep your library within the limits´. I confess that I ignored these for years thinking ´roon is running more or less smoothly on a 5 year old entry-level Celeron so why do they recommend more horsepower?´. As my library was growing beyond the 150k threshold and the little machine collapsed under the load earlier this year, I knew why and made some tough choices like migrating the big portion of my library which I am not using regularly to an external drive. Was kind of a purge for me as a music lover and collector but really brought the roon experience back.

1 Like

Single threaded processes can still be deployed on more than one core - as the OS can move them from core to core in order to distribute the thermal load (and possibly other reasons). Since, the time slice period of the OS task management is much shorter than the update period of the windows task manager, this can appear as multiple cores used for significantly less than 100% - which is what you are seeing.

1 Like

So we know entering THE can cause problems but when I was looking for The Jam, just typing Jam brings up Pearl Jam as top pick and if search more, I didn’t even find The Jam among the top picks. It’s possible it’s somewhere in the full list. This is not useful. Now if I put in The Jam, it does bring back that artist as top pick but it takes 20 seconds to bring back. Longer than expected.

But all this is just work around. No one should expect us to avoid using certain words or hitting enter right away or whatever tricks people have discovered. And I get that it’s complicated but seems everyone else has figured it out. Roon might be uniquely different but would think someone would figure this out if want to continue to compete.

1 Like

Indeed it does and once upon a time, this may have been a reliable workaround but not anymore. Before Roon started processing “somethings” in the cloud you could be pretty sure that if it was a UI, database or search performance issue, it was probably at your end as your Core was doing all the work. The only variable was the source stream on playback if it were non local files.

Thing is, that’s not the case now. A slow search might be at “their” end now.

Simply throwing more CPU, RAM, Storage or Bandwidth at your core/server may not be as predictable a fix as it used to be.

2 Likes

I gave up on trying to get ARC to work properly months ago but it would be great if the Roon tech team could make some progress with the slow search issue.

1 Like

Yeah I’m all up for progress to be made to the rest of their software. It’s not like that part of the team has anything to do with the search. Would hate for other updates to be stalled just because of what might be some sort of glitch hasn’t been fixed yet. I overall do like roon so would like to see it succeed and grow. That’s the claim being made after the buyout, so we’ll see what another year brings.