Occasional search slowness

Typically yesterday when I was encountering slow search results, I didn’t have the time to answer all the troubleshooting questions. Today when I do… The issue is not occuring. I’ll endeavour to reply when I can.

1 Like

Issue occured 20.31 UK time.

TCP receive window: 3217920 current, 3217920 maximum
0.01 % of packets lost during test
Round trip time: 7 msec (minimum), 290 msec (maximum), 57 msec (average)
Jitter: -
0.00 seconds spend waiting following a timeout
TCP time-out counter: 226
880 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.

0.9705 % of the time was not spent in a receiver limited or sender limited state.
0.0000 % of the time the connection is limited by the client machine’s receive buffer.
Optimal receive buffer: - bytes
Bottleneck link: -
658 duplicate ACKs set

Search for the Beatles took approx 30 seconds.

Search for help took approx 20 seconds.

Playback occurred instantaneously.

Daft punk artist search much faster < 1 second

Loading albums 4-5 seconds

Playback instantaneous

Very intermittent performance.

Using roon remote on pixel 2 but also occurs on laptop with Roon bridge.

Local search instantaneous.

Hope this helps.

Hi @jrd1975,

Thank you for sharing that information. Now that I have the timestamp and the results, I have gone ahead and enabled diagnostics mode for your account and what this action will do is next time your Core is active, a set of logs will automatically be generated and uploaded to our servers for analysis.

Once these are received I will be submitting them to QA for their investigation. While there is not much else that can be done at this time, we are hopeful of making some improvements in this area in a future Roon release, and the diagnostics from your Core will assist with these changes.

I would be on the lookout for when the next version of Roon is released (please do keep a close eye out on our Release Notes Section) and once the next release is out we can circle back to this case and see if the changes we implemented has helped you here as well.

Thanks,
Noris

Thanks Noris. I can see a pattern emerging where this occurs more frequently in the evenings. Also often the first search is slow and then if you repeat the search it’s instant. Do the results get cached? Will wait for updates. Sure you’ll get to the bottom of it all!

Hi @jrd1975,

Yes, the results are cached, so that is what you’re seeing here when searching for the same term again.

If the issue only occurs in the evenings, I am wondering if perhaps there are more active users in your neighborhood using the bandwidth or deeper networking issues? Do you notice slow internet performance only in Roon while this behavior occurs or other applications as well?

Also just in case this may help, does changing your router’s DNS to Google (8.8.8.8/8.8.4.4) or Cloudlfare (1.1.1.1) help with performance at all?

No noticeable internet slowness in other applications. Already using Cloudflare DNS.

Are the diagnostic logs showing anything of interest?

Hi @jrd1975,

Thanks for confirming you’re already on Cloudflare DNS. The diagnostics are showing some similar symptoms to what we’ve seen and identified a fix for but I am also seeing one other strange thing where it seems like you are performing a search for an empty text field at the timestamp you noted. This should not be possible so I have asked QA to look into this error that appeared in the logs.

As for a status update regarding the overall investigation, please take a look at Dylan’s post here:

Thanks,
Noris

Hi @jrd1975,

I wanted to reach out because we’ve just released Roon 1.6 (Build 416). This update includes a fix for some performance problems we believe may be causing some users to experience slowness in Roon. Please give Roon an update and let us know if things have improved for you.

You can read the full release notes here:

Thanks Dylan. I updated this morning. I’ll let you know if things improve!

1 Like

Hi @jrd1975,

Glad to hear that you took the update, I too am hoping that it will improve search for you. I spoke to the team today regarding the observation I previously made, where it seemed like you were performing a search for an empty text field at the timestamp you mentioned.

As I noted before, this kind of behavior should not be possible, so I think something else might be going on here. Just to confirm, you were performing the search directly from your Core on April 17th 20.31? No other Roon Remotes involved during that timestamp?

In addition to updating your Core, can you please send us your database for closer analysis? You can use these instructions to send the database over to us and a shared Drobpox/Google Drive/Firefox Send link would be best to get this over to us.

I look forward to hearing back from you if the new build of Roon has helped and please do send us your database when you have a chance.

Thanks,
Noris

Hi Noris. That search was from my MacBook air connected using roon bridge to the core, which is a headless Mac mini.

Will try and send database this weekend.

Initial impressions of update are very positive. Especially my android phone remote.

Thanks, Jon

1 Like

Hi. Just searched for Hol Baumann from Roon remote on Android. Core was playing music to endpoint. Search was at 14.04 UK time. Took nearly 30 seconds. Ran same search after in Qobuz mobile app and it returns in less than 1 second. Sadly I think this issue still exists.

TCP receive window: 2170880 current, 2170880 maximum
0.01 % of packets lost during test
Round trip time: 9 msec (minimum), 280 msec (maximum), 57 msec (average)
Jitter: -
0.00 seconds spend waiting following a timeout
TCP time-out counter: 229
860 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.

0.9747 % of the time was not spent in a receiver limited or sender limited state.
0.0000 % of the time the connection is limited by the client machine’s receive buffer.
Optimal receive buffer: - bytes
Bottleneck link: -
639 duplicate ACKs set

@dylan

The latest update to fix the artist page is much better thanks. But there are still many other times when going between pages that just sit for 45 seconds at times. The Roon team knows these as well u less they don’t use the product. We can all continue to tell you what you already know?

Hi @jrd1975 & @Paula_Dickerson,

Thanks for the feedback here.

We have seen quite a few reports that the performance changes in our most recent release has helped a lot of users but this appears to not be the case for you here.

I will to be discussing with the technical team on the best approach to troubleshoot this issue at our next meeting and will be sure to let you know what they say.

– Noris

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.