revisiting this thread as the OP. I do think there has been improvement over the last week or so. I don’t recall getting the 40-60 second search delays I was seeing before, but its by no means where we should expect it to be. It’s still very common to have 7-10 second delays before search results are returned.
I do not have a large library (yet). About 5500 local tracks and 2-3000 Tidal tracks.
Hi, and for information. Like many others, I have noticed slowness and different response times in my searches, with response times up to 50 seconds in some cases. The last week I have noticed that the searches have become more consistent with response times between 2 - 4 seconds. Yesterday, I again experienced some searches that took approx. 40 -50 seconds.
Another observation I notice is that when searching, the library contents appear for a short period of time on the screen before it is blanked out. Then the aggregate search result is returned on the screen (local library + TIDAL).
Most of the time I use my Samsung S9 or an iPad as remotes. Same experience with both.
Hey @PerMorten, thanks for the report. I tried to reproduce this on my end, and none of the devices I have here (phones and tablets) behave like that. Do you see same behavior when you search through Roon remote app installed on your laptop or pc ?
Hi, this part of the observation you are referring to only applies when I use my Samsung phone as a remote. When I use the iPad or a PC as a remote, I do not see the same. Sorry a little imprecise description in my first message. The search time up to 50 seconds I have observed on all platforms
But better than w3 search eh 
Some updates–
We rolled out a few changes in the past 72hrs, and have been monitoring intensively this week. As I mentioned above, we have more than one angle of attack here.
The really long searches–30 seconds or more–are operational problems that happen when an individual backend server becomes overloaded temporarily. We’ve made changes that have reduced the frequency of this failure mode by about 97%, but we are still seeing a short window each day–a few minutes right around peak usage for the day, where one or two of our backend servers gets “behind” on processing requests.
One more change is rolling out tomorrow morning to hopefully get the last of this problem squashed, but if it doesn’t play out that way we’ll obviously keep at it. It’s much quicker to iterate on a problem when it happens a few times an hour (like earlier in the week) than once per day (the situation we are in now), because to do a proper controlled experiment at this point, we need roll something out and see how it does through the peak hours.
The “2-5 second” slow search experience is caused mostly by the amount of work done when processing search results + formatting them for display. Yesterday, we released a performance optimization that cuts the per-search processing time in our servers by about 60%. That went live late in the day yesterday (in the US) and has made a substantial difference. Our “end to end” benchmark, which looks at the time it takes the Roon Core to generate a full screen of search results across all data types has dropped from an avg of 3.2s/search to 1.2s/search.
Obviously I’d like that to be even smaller, but this change has really made things feel noticeably better.
That last optimization also improves load times for the artist screen, the TIDAL/Qobuz screens, the playlist screen (when loading TIDAL/Qobuz playlists), TIDAL/Qobuz library sync speed, and the “versions” tab on the album pages.
Finally, a crash that contributed “no search results when there should be” problems for people logged into both TIDAL and Qobuz at once is also fixed as of yesterday evening.
@brian Thank you for keeping us in the picture. It makes it so much easier to put up with the problem when we are made aware of what is being done behind the scenes.
@brian Just wanted to let you know that I’m seeing very significant improvements. Over the last 1-2 days I haven’t had any search take more than a few seconds. Further speed improvements will be great, but this is ‘good enough’ for my needs. Thank you and the team.
It looks also much better on my side. So far no long waits while searching. Also the Qobuz Start page built up fast with new albums of the week. Will test more over the weekend. Hope the speed is back!
Look forward to seeing the improvements when I am back home
Are these server side changes on your end?, My Roon core has not updated since April 25. Roon 1.6 Build 416.
Roons backend servers not the application itself.
Yes, all changes so far have been on our servers. No updates to Roon the app are required.
Thanks very much for keeping us in the loop.
I love the Roon attitude and the system itself with ongoing improvements.
Been back home for a day and whatever has been recently done seems to have improved things. A lot snappier overall not had a really long one yet but not pushed it yet. Still needs that last bit of speed but it’s going in the right direction now.
Sorry guys but I have had some slow searches. Had one this morning which was about 20secs so more work still needed.
It was slow last night for me too, I did notice it was far more consistent over the weekend with 5 seconds or so being the norm.
I can’t complain too much as I’m running on a QNAP nas which is below Roon’s recommended specification, but if I switch Tidal off everything is instant, on a 2500 album collection.
Yep I confirm search delays are a problem Roon is currently investigating this issue I thought I was the only one !! Downloaded files execute instantly Roon search delays range from 20s - 45s.
Playing direct from Tidal ( not via Roon) search istypically between 1 to 4s.
I hope Roon fix this problem soon
George