Since 1.6 was installed, or possibly a few days later my Roon Core seem to choke up and provide very poor performance when Searching or trying to Share an album.
I mentioned this in the thread about the Search-function as I thought the issue was on the Roon-side.
My Roon Core is hosted most of the time on a QNAP TS-470 Pro with an Intel Core i5 3470T-processor. (16Gb ram and 3*6Tb Wd Red in a RAID5 config. Samsung 128Gb SSD for Roon DB) This is connected to my LAN and WAN via a wireless bridge, which provides excellent stability and good performance.
Problem is, after a reboot of the Core everything is fine. Search is snappy, Sharing does just fine, playing back tracks is immediate. After a couple of days the search speed seems to slow, occasionally. This gradually worsens and a few minutes ago I did the second reboot after 1.6.
When trying to share an album using Imgur it takes a loooong time for the image to appear (just the animated Roon icon) and then it takes a long time when pressing the Share via Imgur-button again. This often fails and times out.
Search for a new (or existing in local lib) artist takes forever (that’s about 20-30 seconds in an IT professionals world in the year 2019). Repeated search usually goes a lot faster, around 5 sec, but not always.
Right before my reboot of the Core QNAP app I looked at the perf figures for the QNAP and Roon Server was consuming 25% CPU and 3.2Gb RAM… After reboot Roon Server uses somewhere between 1% and 3% while playing back Qobuz.
Any ideas @support ?
@crieke, o you know if the QNAP can give more detailed information about what’s going bad?
Added screen shot of performance figures about 30minutes after reboot, while playing back Qobuz:
I didn’t mention that i use Qobuz Studio and Tidal other than my 150K tracks local library.
Next time this happens, i’ll disable both services first, then repeat Search and Share…
Last night I also had problems with search as it took forever today it is back to normal (my Rock NUC was shut down during the night).
Thx Fredrik, i read in other threads that lots of people seemd to have issues yesterday and the Roon team did something on their end.
It might have coincided, but my issues looks a lot like they did about a week ago, which a reboot of the Core solved.
Thanks for contacting us.
There was an issue on our end which has since been resolved regarding search. The CPU usage you reported here seems normal to me, I would not worry too much about this if everything is working as expected.
Are things working as expected now or are you still experiencing this issue after a reboot? I agree that your test would be a good one to perform, if it occurs again please do let me know and try disabling the streaming services to see if there is any change in behavior.
Thanks for the input!
All is well at the moment with reasonable search times (~1-4sec) and no issues when sharing.
I’ll update this thread in a few days with the status!
I have been using Roon successfully since my last post here, most of the time a search for “marc bolan” or “led zeppelin” takes 1-2sec. There has been no more slowing down of my QNAP based Core.
No process or memory hoggin’ either it seems.
I conclude the previous issues must have been related to the Roon side issues. All is well!
Thanks for the update! I am going to go ahead and mark this thread as [Solved] since everything appears to be working as expected but if you have this issue in the future please do reach out to me via private message and I can re-open this thread if you think it needs more attention.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.
I have similar issues as @Mac_Rebant, and i need to regularly restart my core to maintain search capability. I cannot click the album links on the “now playing” page, Roon stalls with the animated Roon-icon claiming it’s “Loading album…”. I have to find the album via the hamburger menu.
I agree this is the slowest and most unstable Roon version since 1.1 (when i joined)
It seems we have concensus here, Roon 1.6 (and particularly build 401) have introduced an unwanted behaviour in response. I’m a little surprised that @support has been so sparse with input and suggestions?
I did create a thread about the search times previously but that seemed to coincide with some server-side issues. After that, it seems i have to reboot my Core about weekly to maintain acceptable search times. And, like someone said, i just want to locate an album in my own library 3 times out of 4 and the animated icon of Roon grins back at you from the screen…
My Core has about 130K local files in various formats and other than that i have Tidal (350 albums) and Qobuz (50 albums). Next time the Core chokes up, i’ll disable the Music services to see if that relieves the slowness. Located in Sweden shouldn’t be an issue?
Sorry to hear that the issue is back. We are investigating a few similar reports and I agree that your proposed troubleshooting step here would give us a good data point:
When this issue next occurs, can you please also let me know the exact local time in your country (e.g. 5:16PM) that you experience this behavior? I’d like to take a look at the diagnostics from your machine for that timestamp and see if there was perhaps any unusual behavior being reported.
This is still happening, at times making Roon unusable to me.
I have recently given up on Tidal and disabled my account there. This immediately improved my search times, but it didn’t fix the issue.
To try and be clear:
Search - takes everything between 5 and 30 secs… And, in a system that is based on search and filtering, that is totally unacceptable.
Discover - doesn’n seem affected. This has always been a bit slow and annoying on iOS, so i basically never use it.
Most other functions, such as clicking on hyperlinks in biographies or reviews, are instant. I shift between my NAS based Core and my NUC items. They are equally affected by this and i see no differences in behaviour.
I have been discussing this issue with the technical team on a fairly regular basis, hence Mike’s recent post here: (Build 416 Search Performance Feedback).
As Mike mentioned, we are going to be dedicating some more dev resources in this area to further improve search performance and the data point that you have provided so far will be of great help in this aspect.
One of the more recent questions that could be useful here would be – does this issue occur most often at certain times of the day? For example, do you only see the slow searched in the morning/evening time or does it seem to happen regardless of the time of day?
Regarding the times when this occurs, it varies but i have a distinct feeling it happens more often on what i’d say is high traffic times…
That would mean evenings, say between 18:00 and 22:00CET more noticeable on fridays.
I’ll try and keep this updated regularly.
Edit; My little brave ROCK (NUC8i3) is currently analysing audio after i pointed it to retrieve part of my library from NAS, and partly from internal hard drive. I had a look to see whether it was finished (which it wasn’t) but decided to throw a search at it, “led zeppelin” showed me the Roon jellyfish for 35 seconds and then i gave up… This was at 22.01CET if it is of interest! I could do other stuff quite swiftly, such as settings, show the overview etc. I still have both Qobuz and Tidal active on this core though.
And now, at 06:57 i tried a few searches from the same core as i reported in the previous post.
“led zeppelin”, “marc bolan”, “genesis” and finally “yes”; All of them returned results in no more than one second!
I disabled Tidal last night, but still got Qobuz active, and now the audio analysis is also finished.