I have RoonServer v1.2 (build 128) installed atop a Linux Mint 17.3 install (kernel 3.19.0-32, 16GB of RAM, Xeon E3-1225 V2 processor). The library of music this instance has been asked to serve is relative large (a bit under 250,000 files).
This Core doesn’t seem to be making any progress with background audio analysis. This is what’s displayed in the Setup tab of Settings:
…and it doesn’t appear to be changing. The number to the left of the slash is always zero, and the number on the right only appears to go down when I play a track, which I assume is triggering on-demand audio analysis. (Am I correct in understanding that audio analysis is what produces a track’s level graph and info for use by Volume Leveling?)
Background audio analysis speed is set to “Fast” above, but I’ve tried “Normal” as well, with no apparent change in behavior. I’ve seen the number of tracks remaining to analyze stay completely unchanged after leaving this Core running for two days over a weekend. Per top(1), there is still unallocated RAM in the system with none of the available swap currently being used, so I don’t think Roon is memory-starved.
Of course, after having looked for related topics before posting, right after posting this I found one from 2015 which suggested the workaround of turning off background processing then turning it back on again. This does indeed appear to have un-stuck things: the numbers to the left of the slash are counting up for the very first time in this installation’s life.
Leaving the bug report in case someone wants to look into the cause of the original stuckness, but it’d be fine by me if you choose to remove it.
I think you’ll find it stall periodically and at times you won’t be able to turn analysis off or change the setting. At that juncture it’s time to restart RoonServer.
…and you turn out to have been precisely correct. After my stopping and restarting of background analysis as detailed above, I saw the counts on the left marching steadily upward as the total to-do of 224807 remained constant.
I checked back in an hour to find that the to-do number on the right had dropped to 218540, but the number recently done was stuck at zero. …and this time, changing the “background audio analysis speed” to off then on again didn’t cause analysis to restart.
Interesting. I also note that while in this state where no background analysis progress is being reported to the remote Roon UI instance, top is reporting high (up to 160% and change) CPU usage for the RoonAppliance process, which is higher than it was reporting while the analyzed-track count was counting up. Has a thread busted out of the stable and started galloping around on its own?
I’ve restarted the Core on the Linux machine. I’m now waiting for a 21,000ish-track “Adding Music To Library” operation to complete in hopes that the Core will let me resume background analysis after that’s done.
(No new music has been added to the watched directories, but given the messy state of the tagging in this library, is it possible that the 21k tracks Roon insists on re-adding after a Core restart are the ones it hasn’t yet been able to identify to its satisfaction?)
Another observation… analysis eventually reached a point where it was reporting “0 / 199447” and got stuck there. After some stopping and restarting of background analysis, eventually things got into a state where the “Analyzing:” counter just never came up again after analysis was switched back on.
I took a peek at RoonServer_log.txt, and I saw that whenever background analysis was turned back on, there’d be a log entry about beginning analysis, like so:
…but there’d just be the one, and the count in the user-interface Roon instance would never appear.
I tried searching for and playing the above track.
It started playing, but with a flat line instead of the usual levels graphic… and the levels graphic didn’t pop right in after play started the way it usually does when to on-demand analysis is able to do its thing.
The track played for awhile… then just stopped partway through, and awhile after it had seized up, this appeared:
…and after that, play just stayed jammed up, I couldn’t play another track until after killing and restarting a bunch of stuff.
So apparently, this cycosmos.mp3 must be a poison file in some way. I’m not sure in what way - I was able to turn it into a WAV no problem using madplay - but in case you want to eyeball it, there’s a copy here.
After some stopping and restarting of background analysis, eventually things got into a state where the “Analyzing:” counter just never came up again after analysis was switched back on.
Same I have here… Never wants to start again after it hits some specific count/file…
Hope this can be fixed soon and our libraries van be analyzed fully
My last report above is of observations made after restarting, waiting for initial watched-directory scans to finish, and waiting for the usual re-adding of a subset of the unchanged library to complete. It just didn’t seem necessary to recount that part again.
Hi Jeffrey,
I just pulled down that .mp3 file from your link and tried it on my Roon system … seems ok.
Though I am running a slighter later Roon build that you.
This is what the waveform looked like.
It’s encouraging that your Roon build was able to make it through profiling this file! Are you running the Linux flavor of RoonServer?
Well, no, it moved on to a different file to try to scan next… and then hung there.
My case may be pretty extreme… this is a big, messy library of music collected over years by a number of people in order to make those tracks available in-house for radio DJs to use on-air. The quality and provenance of the tracks is extremely variable. So… manually quarantining files correlating with misbehavior, one by one after observing a scanning halt, seems a hopeless task. I’m hoping for more robustness in the face of troubles.
One datapoint: after filtering out duplicates across restarts, I found 20,794 tracks (of the nearly 250,000 total) which Roon flagged “Failed to extract audio format […] CorruptFile” in logs. But I’m not finding the files at which scanning is stopping in that CorruptFile list (so presumably Roon does flag those CorruptFile files as to be ignored later in that uptime instance).
Of course I don’t know that the reason scanning is stopping is necessarily because of poison files. I don’t really know what’s going on, I’m just guessing wildly and hoping someone with keys to the clue closet will get an idea.
