Sorry @daniel I think asking a customer to rebuild their library is a bit much. This is a problem that creeps up far to often and many posts on this topic none with a clear answer. Mine from October last year was cloesd and not one support reply!! Audio Analysis keeps getting stuck - #6 by Menzies. In some cases it might be a corrupt file but in mine the way it displays indicates its not and its not all the time.
I know this issue affects two other users quite often when importing in large amounts of tracks.
In my findings say you import 50 fiiles it may get it stuck at 49/50.Stop/start analysis it clears, however if you add another 30 files it will get stuck at 28/30, add in 15 next time it wiill get stuck at 12/15. See a patten here. Rebooting or restarting the server, will clear it completely unitl next time it decides to have a blip and then it will be back to just one of the batch you added that will get stuck, its not the same file everytime. If it is down to corrupt files or an incomplete analysys then there needs to be better reporting in Roon, you cant expect a customer to work out what this will be.
@daniel - having continued to observe closely the stalls, I can confirm that:
the ‘current’ and (presumably a calculated) ‘total’ numbers don’t immediately seem to me to correspond to (recent) imports… for example I just imported this set of 11 CDs; nowhere can I see how 1,508 could correspond to a figure in any new or recently-updated track total in my Library, or the delta with last time. Is this something that you would elicidatre for us, please, Daniel? Thanks!
the stall always occurs five tracks from said (presumably a calculated) ‘total’ number:
Hi @Mark_Sealey,
We’ve spoken to our dev team about this issue today. We have discussed several theories, but the most likely one is that Roon was still trying to analyze these 5 files, but there was a timing issue and the album IDs changed in Roon as analysis was taking place. Our QA team is trying to reproduce this scenario in the lab to see if we can observe this live, but testing for this takes some time, we will let you know if we require anything else for testing this. Thank you in advance for your continued patience.
Yes, you can access logs with the following instructions:
The QA team is trying to get to the bottom of this, but we have not yet been able to determine the exact files affected or how to reproduce behavior on our end yet. We’ll update you when we have more details to share from QA.
I have located the logs in question, I think; on my Nucleus from my iMac Pro (13.6.4):
/Volumes/Data/RoonServer/Logs/RoonServer_log.nnn
Yes?
I can carefully copy (ie not move!) the current (e.g. 'today’s date) log to my desktop and examine it in BBEdit.
I can correlate from my system clock when the stall appears to start.
But what exactly should I be looking for, please?
OR, when you say:
should I understand from this that your servers themselves ‘know’ which FLAC (etc) files I have stored in Roon and that your team is examining this correlation?
If so, maybe I should hold off trying to make sense of the log files.
In any case, may I thank you - again - for your persistence with this! It’s much appreciated - from a lifer fan !
You can replicate it by moving an album directory or rename a file whilst it’s processing it will get into this state from their on adding in any new material. If you stop analysis it will clear temporarily until you add some more, a restart of server seems to clear it. It would be handy for Roon to have a feature that will identify which files have failed to analyse then a user can possibly fix it and then perhaps a reanalyse. We have skipped files so this would be an extension of that.
I’ve got confirmation there is a internal ticket for this behavior. I’ve seen it on 3 totally different roon setups. Nucleus, rock and a roonserver on ubuntu 22.x.
It’s easy to trigger this. Just rename one or a couple of folders on your storage roon is watching and the audio analyses stalls at some point. Same for renaming, adding metadata to files on the roon watched storage
Hey @Mark_Sealey !
Thanks for your patience!
According to the logs, It is not so obvious to understand what is going on. So for the next part of the investigation let me ask you to do the following steps to figure out which tracks from your library have problems with analysis:
Go to the Nucleus web page in your network, (eg. 192.18.x.x, depending on your device network address) and click the Restart button. This will restart your Server.
Let it work for 5-7 minutes
Repeat Step 1
Let it work for another 5-7 minutes (no need to play the music)
Archive the whole Logs folder at /Volumes/Data/RoonServer. You may share it via any cloud storage you are using
Yes! Could well be! But it does look to me (as @benjaminsays) that:
Which would be good to know… maybe an underlying bug that, because it can be triangulated from (at least) three (somewhat different) sources and behaviours, can relatively easily be fixed.
It’s indeed the counter or forked process for audio analyse that’s stuck but (my theory without the source code):
Audioanalyse starts when there is a change in the directory('s) watched by roon (logical).
Whenever I move/copy change something in the watched directory audioanalyse starts and gets stuck in the end because the original folder is changed or even not there anymore.
Solution: add a timeout how long audioanalyse can run on a specific file and after the results/output of audioanalyse check if the file still exists in the same location, if not discard the output of audioanalyse because it’s not relevant anymore and don’t try to add it to the database of roon where the file is gone in that particular location.
This whole thing never happened in earlier 2.0 builds of roon…
!