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…
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?
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…
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:
´my battery is not charging properly and loosing capacity in -30 deg centigrade´ writes a guy from northern Norway
´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:
Underpowered CPU without user ever noticing it as roon ´just ran fine´ before the last update
large library well above 250k tracks, unorganized folder hierarchy or well beyond the capacity of the CPU/RAM used
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:
bought a new server with more powerful CPU (which was not an easy choice as I wanted to stay with Qnap and HDDs)
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
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
