Do regular (daily) restarts of roon have a negative impact?

[Joachim_Herbert]

Roon Core Machine

HP Prodesk 600G5 SFF, Intel(R) Core™ i7-8700, 64,0 GB, Windows 11 Pro, 23H2, 22631.2861

Database on internal NVME, Media on WD MyCloud (24TB)

This machine is used by roon only

Networking Gear & Setup Details

FritzBox7590, 1GB Ethernet to Core and NAS, WiFi to Clients. Internet Deutsche Telekom DSL, 100 Mb downstream, 40 Mb upstream (rock solid, low latency)

Connected Audio Devices

Pi3>USB>Matrix X-SPDIF3>AES/EBU>Genelec 8361a>AES/EBU>Genelec 8361a
PC>USB>RME ADI-2 DAC
Chromecast devices
Airplay

Number of Tracks in Library

Pretty large

Description of Issue

Question: Do regular (daily) restarts of roon have a negative impact?

Background:

Roon starts slowing down after one day of operation and does not move anymore after three or four days. This comes with a constant cpu load well above > 6%. Memory usage starts around 12-14 GB in the first hours of operation and then steadily goes up close to 40 GB.

I am under the impression that roon starts housekeeping tasks after a certain time of operation that bring down the whole system.

I moved roon to a dedicated machine, expanded memory to no avail.

I recently bought another machine to host rock. This did not work for me for various reasons (no proper restore of database, unexpected background audio analysis of all tracks which were already analyzed, no way to monitor machine…) and I gave up on this.

Playback, search, adding tracks work just fine up to 24 hours of running roon server and just goes south from there on.

The only way to enjoy roon is restarting, which is fine with me but might have side effects I am not aware and would like to learn about.

(I know that the system configuration listed above is not compliant with some suggestions made by the roon team. This is true for file storage and wireless connections to clients. I am well aware of this, and I am sure that both do not contribute to the problem. Same thing happened for years with an earlier system with local storage and a wired client.)

[Henry_McLeod (Henry)]

Your machine doing what it does (seemingly a memory leak) is a fault. Restarts simply mask the issue. Get your issue diagnosed properly and then fix what the diagnosis reveals. It may be Roon, it may be the PC, it may be Windows. But sort it rather than mask it.

[Joachim_Herbert]

I know, @Henry_McLeod. I know for sure it is roon. Hence the question if restarts hurt. Because that’s what I will do until they fix it.

[Bill_Janssen (Wigwam wool socks now on asymmetrical isolation feet!)]

No, there should be no side-effects.

[Henry_McLeod (Henry)]

Restarts do no harm. But helping obtain a fix does some good. Hopefully once Roon are back off their break they will be able to help with a permanent fix.

[Marin_Weigel (Bram Stoker's Cappuccino)]

@Joachim_Herbert

Question: Do regular (daily) restarts of roon have a negative impact?

Answer: As others already stated, no. I’m doing it for four years without negative impact.

Suggestion:
Check your Roon database backup location and make sure it’s not within your Roon watched folders, since that may be be a reason for your troubles.

[Joachim_Herbert]

Thank you, @Marin_Weigel. Backups are on a different volume. Did you ever find out why the restarts are needed?

I wonder why roon simply does not last longer than 24 hours or so. Just came across a thread where this happens with 60,000 tracks under Linux, if I remember correctly. This does not seem to be limited to Windows and large libraries.

[Marin_Weigel (Bram Stoker's Cappuccino)]

@Joachim_Herbert

Did you ever find out why the restarts are needed?

Restarts are not technically needed with my setup.
It just makes me feel a little greener.
And why should I leave my Roon server on when unused - I’m not using ARC, anyways?

[connor]

@Joachim_Herbert,

We’ve taken time to look through available diagnostics and reviewed previous cases concerning ongoing poor performance.

There are always ongoing efforts to debug and improve Roon, and at times, you’ve encountered known slowness related to search indexing or other processes that we have improved.

But we need to set expectations and limits concernign library size and, more importantly, the breakdown of the content within the library. The common factor across all of your poorly performing setups is your library of nearly 850,000 audio files, nearly a quarter of which are entirely unidentified by Roon’s flexible and vast audio analysis service. When that many audio files are atypical - as in, music outside of the metadata and royalty network - then Roon will inevitably perform poorly. That is an order of magnitude of unidentified content for which professional radio station catalog management software will be necessary; it is not an audio consumer use case. Additionally, libraries this customized, on user-end platforms, often source from subdirectory structures wildly outside of standard music industry consumer taxonomy.

This is the reason Roon’s backend services like audio analysis spin endlessly. Anytime you make a change to your library, Roon will attempt to identify the upwards of 150k audio files that are not officially released or recognized music.

Roon is not a professional file management service, nor is it a massive metadata curation service built for a professional radio station. With a library your size, you are simply outside of the consumer audio use case and outside the scope of support.

This thread will move to Tinkering in the meantime.

[HeavyMetalDrummer]

@Connor This post is fascinating. In my case, my library is 96,000 tracks and 5600 albums. I have a large number of concert recordings from a small number of artists that are unidentified. 791 albums and >17,000 tracks are unidentified. They are very well organized using standard artist/album/track folder structure, and they have robust metadata contained in the files. It never occurred to me that could be causing the very poor search performance of my database…

I am tempted to make a copy of my library, remove all the live stuff, and see what happens.

[Joachim_Herbert]

@connor I wish it was that simple. I just checked about ten unidentified albums against musicbrainz and discogs and easily identified most of them. Which means that “Roon’s flexible and vast (fast?) audio analysis service” is not up to the task.

We have two issues here: Less than perfect identification of music and poor handling of issues resulting from this.

I am attaching some screenshots. I could go on checking these, but it is a time consuming process, so I leave it to theses examples.

All searches were done with songkong.

The first screenshot is from the log, just to show where the samples are from.

[Geoff_Coupe]

At least some of these albums are known to Roon since they are found by Roon in the Qobuz catalogue when searched for. For example:

What happens if you try a manual identification?

[Rugby (aka Daniel or Big Dan)]

It may be regional as well, I cannot find that album in Qobuz in the states, but, I do find it when I log into my UK Qobuz account.

[Andreas_Philipp1]

@connor

But we need to set expectations and limits concernign library size and, more importantly, the breakdown of the content within the library.

You make some interesting points here, but don’t really give clear answers. So, just to set the expectations and limits to easily graspable values, what is really the limit of library size supported by Roon’s software?

I always understood that there is no hard limit, but your post sounds as if we users had to take into account limits, which are not at all clear to me. How many local files, how many tracks from streaming services?

What is the reason unidentified local files impact negatively Roon’s performance? What would be a reasonable fraction of unidentified local files still being considered within expectations and limits?

What are other considerations to take into account with regard to our libraries, other than configuration of our server hardware?

@connor

There are always ongoing efforts to debug and improve Roon

Yes, I can confirm that, as the last two releases have very positively impacted the memory management of my Roon server on Ubuntu 22.04. When previously I had to restart the server at least every 5 days, today I had reached 22 days before the forced restart because of the new build.

Still, I observe processes which apparently don’t free resources and by doing so contribute to a slow performance degradation. One example is the metadata update service, which vastly increases on my server the reported file handles, which stay vastly increased, even after this process has terminated.

The metadata update as such runs ever more slowly with increasing server uptime. The same can be reported for the Qobuz and Tidal library indexing processes. These run very fast on a recently started system, and slow down ever more with increasing server uptime. This, without the system ever getting even near its physical memory limit. I have reported this before, but have never received an answer as to why this may be so…

In addition, that all these processes run on one single core and keep this core at 100%, slows down all user interface interaction which depends on info from the library database, while these processes are running on the server. I am sure there is ample opportunity to enhance and debug processes which have a great impact on Roon’s performance as experienced by the users.

[Joachim_Herbert]

To be honest, there are several CDs ripped from my collection, that are not found in discogs or musicbrainz.

These are from German and European artists mainly.

But these are properly curated and tagged, so Roon should be just fine.

[Joachim_Herbert]

No, will try tomorrow.

[CrystalGipsy (Resisting the flow!)]

Being in Qobuz or Tidal isn’t part of Roon identifying any album it just happens to be available in those services nothing more nothing less and it’s not a local file that needs identifying. I have a number of albums that my own copy is unidentified but it is available in Qobuz. If it’s not in MusicBrainz or Allmusic it’s alway unidentified even if you group them together.

[Geoff_Coupe]

@Simon_Arnold3

I have a number of albums that my own copy is unidentified but it is available in Qobuz.

And for cases such as this, I’ve been able to do a manual identification to get a match - but perhaps I’ve just been lucky.

[paultaylor]

FYI in case you were not aware some of the albums that were matched by SongKong such as Graham Bond one or the Janne Schaffer show the MusicBrainz match in dark blue rather than light blue, and not all songs were matched. This indicates a MusicBrainz Song Only match which means we could accurately identify the song but we could not identify an album that would allow all songs in the grouping to match, in such cases we modify song metadata such as song title but leave album metadata such as trackno or album untouched.

When this happens it usually means either:

• MusicBrainz has a version of the album but with different track listing to what you have
• One of your track has a different track length to the one on MusicBrainz due to some encodiing issue

Both of these reasons will prevent a Roon because I think Roon only matches complete albums, and the track length is part of the matching algorithm.

Also please be aware regarding SongKong matching that you dont have to match album at a time you can point SongKong at the whole music collection and do in one go.

[CrystalGipsy (Resisting the flow!)]

No such luck for me they are not in Roons metadata services at all so remain unidentified. Yours must have been in them but failed to match. I’ve gone through all my unidentified albums so many times manually but no such luck and checked them in both Allmusic and MusicBrainz and no entries.