BackGround audio analysis speed stalls [Investigation Started]

Support Nucleus Support
23

Have been trying to determine a pattern.

Just done a large import and watched.

On the surface, that import of 217 tracks, 2.72 GB seemed to ‘cause’ the previous hang to resolve itself and the number of tracks needing to be analysed rose easily to 515 - as in this screenshot.

The number actually processed also rose equally swiftly. Until coming to a halt at 510/515, which seems pretty typical: the ‘stall’ (if that’s what it is) usually (but not always, I’d say) occurs within half a dozen of ‘completion’:

Screenshot 2024-02-09 at 16.17.53
Screenshot 2024-02-09 at 16.17.53976×538 14.7 KB

24

It’s been a bug as long as I can remember. My solution these days is Settings > Library > Background audio analysis speed > Off and then back to my previous setting (Fast (2 cores)).

1 Like
25

Yes, I do that too, @DDPS, after you kindly suggested it elsewhere. But I wait a few minutes after it appears to stall - just in case by doing that I’m allowing it really to finish.

1 Like
26

The count of unfinished grows until you reboot/restart Roon server, the stop of analysing in background won’t clear that. If you don’t reboot it will keep on growing, everytime it has another blip. Only restarting it clears it back to 0 then it will be 1 at next blip.

27

It does for me. But I wonder if that’s because I’m on Roon on NAS and I don’t have it scanning for new files in real time.

28

There is no options to turn off realtime scanning do you mean the background analysis? This is purely to make waveforms and get dynamic ranges this is what breaks here. When setting up a watched folder you can set the library rescan interval to be when started or a scheduled one every x hour is this what you mean? Thats for picking up changes to the library which is a different process to the analysis stage. But it is triggered by the scanning of files. But it will always pick up realtime changes regardless and no way I can see to turn that off.

29

Well it’s not an option per se, but default NAS configurations have limited file handle monitoring and need a “Force Rescan” operation each time after adding music. People often complain about this, but I actually don’t mind it. It takes like 8 seconds to scan, and it’s not like I am adding music 24 hours a day, although I might wish I was. :slight_smile:

2 Likes
30

How sure are we that it is the server which has the bug?

I have restarted Roon Server (by virtue of my daily machine restart) and still see the stall when I launch Roon (which is 2, 1365 on macOS 13.6.4).

Like @DDPS I don’t mind either Force Rescan, which takes <5 secs (fewer than 500 Albums in Roon so far :slight_smile: .

1 Like
31

Always clears it for me and doesnt do it again, when adding new music. Unless I cause it to fall over by editing or moving whilst its processing.

32

That ought to provide @daniel and team useful data to go on, oughtn’t it. In the sense that the (apparent: I still like to think it’s an interface, rather than an actual database, bug) stall does seem to behave differently for different users.

I say this because - after I read your post today - I felt sure that restarting my iMac Pro (13.6.4, Roon 2, 1365) would have caused the scanning to be suspended or finished.

But No. As a matter of fact, Settings > Library > Library maintenance revealed exactly what I posted last night: 510/515!

In a way that’s re-assuring, in the sense that Roon is successfully keeping track of what it thinks still needs to be done.

OTOH, changing the setting in the dropdown does always ‘fix’ it.

33

It’s definitely not a ui bug as it’s present on all remotes when it does it. So indicates it’s a Roonserver process getting stuck. This isn’t unique to RoonOS either as it’s happening on plain old Linux version to that I am now running. @support can we please get some traction on this. There are many posts about this behaviour over the last year or so and nothings been done to fix this. I raised my own ticket last year and no solution.

35

@Mark_Sealey we’re going to bring this to the QA team.

2 Likes
36

Great; thanks, Daniel!

I think (but I’m not 100% certain) that - although I used to experience this from time to time before I got my Nucleus last November - this many instances may be associated with that. Although, of course, that’s also roughly when then Roon architecture changed as it did to two separate applications.

Ready to help in diagnosis in any way I can :slight_smile: .

37

@daniel,

Addendum: I’m quite prepared to told this is just fanciful, or that it’s co-incidence; or even that I’m imagining things. But the last few times it’s stalled, it really has always been exactly five tracks before the final one (currently 1309 / 1314, for example)!

Hope this helps :slight_smile: .

39

@Mark_Sealey,
So it looks like analysis is getting stuck on a specific track. Likely a demo or some other unique recording. We will continue to try to identify which track is causing the issue. That may take some time. So you might want to look at the most recently added tracks when this started happening.

2 Likes
40

Thanks, @daniel!

I hear you, loud and clear. Appreciated!

But - doesn’t the fact that it always happens - whether I import, say, a four movement symphony, or a 98 track song collection - argue against of the ‘specific track’ theory?

If for no other reason than that there’s almost no possibility that all the other users reporting this have the same potentially rogue track as I have.

What’s more, there are times when analysis (appears to) complete(s). But re-appears on the next import.

Doesn’t that suggest that - again - that, for the ‘specific track’ theory to be correct, each import which I perform must always have its own ‘specific track’ that is usually situated five tracks from what Roon (seems to) know(s) is the last one to be analyzed?

May I ask this, please, Daniel: for it to be a specific track somewhere (I can imagine how it may be hard for you to find it; but thanks for offering to look!), wouldn’t Roon always have to re-analyse everything in my Library every time I import anything? Isn’t that the only way that Roon would come across the same track? Perhaps that’s what Roon’s analysis process does, is it?

Please do. I suspect (respectfully) that this may be a more widespread bug, as the many others who experience the same phenomenon suggest.

41

It’s possible that the problem files are never marked as analyzed and so are reanalyzed each time you add music. You are correct that analysis does not rescan your whole library each time.

1 Like
42

Thanks, Daniel: I often Force a Rescan. Is there anything else I can do to try and isolate what you and your team think may indeed be a corrupt (?) file, please?

43

The best suggestion I can make is to identify when these problems began and start with the files you uploaded around then and test if they’re the problem.

44

Daniel,

Thanking you and the team again for pursuing this…

As I said the other day, I have the impression that I first noticed this happening 9 times out of 10 when the Roon architecture changed to the separate Server; that was November, wasn’t it.

Unfortunately, that was when I also bought my Nucleus (Black Friday :slight_smile: !); and so when the location of Roon Server/Storage etc changed from my iMac Pro to the Nucleus. At that time I was able to save then re-import from my Roon database backup - as described here etc - without error.

Since then I’ve probably doubled the size of my Library - to over 10,000 tracks.

Hmmm; I’m feeling that it’s not really practical to re-import and retag etc in Roon 5,000 files, is it?

Again, my apologies for not completely understanding, please, Daniel this:

If, say, there was a ‘corrupt’ (or otherwise ‘misbehaving’) file that was one of those 5,000 new ones, imported, say, on January 1, is it the case that Roon keeps trying to rescan it every time I import a new set of files/tracks; and that it somehow works its way into a position fifth from the (‘new’) last file in my Library?

What’s more, I’m certain that several times (since November) the Analysis process has finished. And recently. Doesn’t that suggest that, if there is a faulty file, it has at least once successfully made it past the stall?

Not trying for a moment to be ‘contrary’; grateful for your help :slight_smile: ! Just trying to follow the most productive path. Thanks.