Does Roon team acknowledge the search issues?

outstanding!

Yes it’s being looked at and they are taking feedback from users effected by it, changes are being made I believe none have had any effect yet though.

1 Like

I did receive a note from one of the Roon team members a couple of days ago regarding this. They are working on it and also have made som changes on their end.

I have not had any search issues since a few days and all searches returns results within 2-3 seconds at most. I have, however, disabled my Tidal account, as I have gone over to Qobuz for streaming services.

So, it’s definently something that is under serious scrutiny, no doubt!

The only “acknowledgement” that matters is one in the form of a fix.

3 Likes

True I received the same note as Mikael, tweaks they have done have made the base level quicker but still 3-4 secs which is still too slow, but it still gets times when it just chokes and I am waiting up to a minute. Seems to happen after doing a few searches in a row or just randomly, Its not consistent.

There are lots of things going on to improve search. It’s not one issue, and not all of the stuff that is impacting search is specific to search. I can elaborate on some of it…

In the most recent release, we rolled out a significant optimization for how the core handles out-of-library objects–search is a heavy consumer of this infrastructure. This fixed a primary cause of slow searches at that point in time and also reduced Roon’s background CPU usage in general.

Once the dust settled on that release (2-3 weeks ago), it enabled us to survey what remained. At that point, we discovered a root cause of 30-60s searches/timeouts, developed a fix last week, and rolled it out at the beginning of this week. As far as we can tell, that failure mode is over, and the next goal should be about getting currently 1-5second searches into the hundreds-of-milliseconds range.

The search index itself is adequately quick. Most of the time goes to either results processing, rights processing (determining which content you are able to see based on the TIDAL/Qobuz regions you are logged into), and formatting the results for transmission to the app. Search is one of the heaviest pages in the app and leans hard on a lot of infrastructure.

This infrastructure performs the same as it always has, but search has a much tighter responsiveness expectation than other pages, so it is forcing us to rethink a lot of how that old stuff was built. Much of this stuff was built long before we formed Roon, some as early as 2012, and at that time we were building a different product with a different set of goals. Re-building a lot of this is healthy and necessary, but not instantaneous.

Anyways–that infrastructure is about halfway through a ~6 month optimization project. The first half of the work is poised to roll out next week, and speeds up the most expensive steps by about 2x. The second half of the project is underway, and should yield a similar scale of improvement.

This project also enables us to deploy a more sophisticated worldwide caching system that will help reduce round-trip latency for everyone when loading data in Roon. This project is not search-specific–it will affect almost every screen in the app that loads data from our servers–but as one of our heaviest screens, search should benefit substantially.

We have another project in flight to multiply the capacity of our search backend by 2-3x and design a faster and better indexing process. This will help the speed of new releases getting into the search index. In parallel, we are also working on the latency of new releases showing up in Roon in general, both by coordinating with upstream providers, and by re-organizing some of our internal processes. The difference will be substantial once all of that work flows through. The larger-capacity search backend will also enable us to make the searches themselves more expensive–enabling us to re-attempt fuzzy matching, or otherwise improving the queries/results quality by spending more compute resources per search.

There are a collection of smaller projects related to search–building a better benchmark for search results quality, and tracking down a few minor bugs. This stuff is also in flight.

There is so much going on here that I’m sure I’m forgetting something…these infrastructure/backend projects take a lot of time and do not make for splashy product releases, but we have to do them. Roon has to get faster, and it has to do that while our user base continues to grow rapidly, and without breaking too much along the way. Not an easy problem, but one that has consumed a lot of our attention in the past few months.

56 Likes

Thank you for the update on the work in progress @brian.

Much appreciated.

@brian thank you for detailed explanation - aren’t you considering having some kind of Roon CTO blog - sharing similar insights, where people could see what’s being “cooked” ?

4 Likes

Thanks for the reply @brian is this rollout of the latest fix regional or centralised as I have not noticed any change to the long lag searches yet. Was still getting them Thursday evening not had chance to test now as I am away for a week.

Thank you @brian. Like @CrystalGipsy I’m still experiencing sporadic long searches (40-60 secs). I’m hopeful that the teams’ hard work will pay off soon. I also just want to let you and the rest of the team know how much I’m enjoying Roon. Lots of gripes in this community but I guess it’s just due to a passionate user base. I hope you all know how much most of us appreciate what you have created.

2 Likes

I can confirm both, at least from my perspective :slight_smile:

That fix was global–as far as I know we were measuring long searches in our services before the fix, and are no longer seeing them now, but I will double-check with the team in case something got left behind in that rollout.

Yes, thought about it, and will continue to.

3 Likes

I think that would be a good idea, I’d love it. (Not the continuous thinking about it, but turning it into action :wink: )

5 Likes

Simply thrilled with Roon. Glad to have this forum to see that the my expierences are not unique and folks are working on things, lots of things!

Well I would say from other recent posts that the longer search’s are still happening and whatever has been rolled out has not 100% sorted it.

Agreed. Using Roon yesterday, most searches were fine, but every so often, one would take 30 seconds or more–a real headache when one’s trying to queue up tracks from various sources.

@amg, guys, lets hear about your libraries?
I recently abandoned my Tidal, and kept Qobuz. In my case that coincided with Roons lates server-side roll out. My search times have radically improved and are almost back to 1.5 performance.
I have about 130K local tracks and about 100 Qobuz albums in my library.

I still have this problem. Either I get search results right away or it takes about 30 seconds. So it would seem that you fix does not work for everyone.

Just to be clear. This problem is new to me in the last week or two.

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.