Roon stuck on Audio Analysis infinitely

Core Machine (Operating system/System info/Roon build number)

NUC7i7BNH 16GB RAM, Files live on this machine
Roon: ROCK Operating system Version 1.0 (build 227) stable
Roon server software: Version 2.0 (build 1133) production

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Hardwired LAN. CORE and NAS directly hardwired connected to router.
Files on Synology DS415+.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Roon endpoint Sonore OpticalRendu version 2.8
Connected to LAN through Uptone EtherREGEN

Description Of Issue


Since a few days I noticed the fans of NUC7i7BNH running continuously.
It seems under settings - library - Background audio analysis speed setting (on Fast 2-cores) that the analysis is running infinitely.

I have done the following:

  • Reboot ROCK
  • Reinstall oldest backup
  • Removing all added albums and tracks since the last 6 weeks, when problem did not occur, from NAS

Issue persisted, so:

  • Resetted Roon Database & Settings
  • Restoring oldest backup

Issue persisted, so:

  • Moved CORE to MacOS
  • Restored oldest backup

Issue persisted, so:

  • Replaced SSD in NUC7i7BNH
  • Fresh install Roon ROCK
  • Rebuilt database

Issue still persisting. There must be a music track on my NAS messing things up. But the track is older than a month, and I didn’t have this issue before.

My question: how can I see which track is causing the problem, so I can delete it?

Maybe it helps to notice another strange phenomena:

  • After each storage refresh, under Library Maintenance, “Clean up 22 files” appears. I clean up, then “Clean up 0 files” appears. They seem removed. But, after a next storage refresh, without any modifications to files on the NAS, again, , “Clean up 22 files” appears. I clean up, then “Clean up 0 files” appears. May be related. Question, how do I find out which 22 files are at stake?

I have seen previous cases like this on the forum, apparently only Roon support staff can see logs so I will wait until they help me.

In the meantime, I would recommend the developers of this functionality to add a time-out to the background audio analysis, and when the timeout expires, push the file in question to the ‘skipped files’ list and ignore it. Then users can figure out which track is the culprit and prevent CPU to run 100% endlessly. A waste of energy for users that don’t notice this. Would this be a viable feature request?

As I’m not getting any response here, I’ve been exploring myself. Found the Roon log files on my NUC and went through them. I’ve found that if you search for occurrences of “music/storage” you find problems with files. I see cases of “ignoring add for auxfile” on JPG folder files that are already in the library, which may explain the 22 deleted files that reappear each time. No idea why this happens, maybe because the JPG is in the FLAC ID3 tags and in the folder?

Furthermore I find a lot of errors on one particular album, errors like “undeleting track with same file key” - I will remove this album, reboot and report here if it has solved my issue. Fingers crossed.

Yes! It worked! I’ve deleted the album and now the problem is solved. After a scan, no more 22 files to delete and no more endless background analysis. So if you have the same issue, find your logs, search for ‘music/storage’ and go through the issues and delete the album(s) in question.

Topic can be closed!

1 Like

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