Multiple rescans of library needed for albums to show up on Linux 5.X Kernel & AudioLinux [Ticket In]

For the past few weeks, I have had problems with my library scans. A different number of albums shows each time I scan, sometimes the number oscillates wildly by hundreds. Usually if if repeat the scan 5 or 6 times, roon will find most (all?) of my albums.

Here is the relevant equipment list:

NAS: Synology 1813+
Switch: Cisco SG110D-05
Roon Server: Nuc8i7hvk with AudioLinux
Roon Version 1.6 (Build 4.16)

Both nas and computer are connected to the switch with ethernet cables.

I’ve removed duplicates and tried to clean up my library as much as possible. My computer is very fast and performs a scan on over 9000 albums in only a minute or two, but it would be even better if it would perform that scan accurately. This morning I couldn’t find an album I knew that I had and had to rescan again 5 or 6 times in order for it to show up — and then it had lost all its related information, tags, times played, etc. By the way, I have my library set to scan only on restarts.

Is there any way to troubleshoot this?

Hello @ronfint,

Can you please share a screenshot of your “Activity Spinner” page when opened (after performing a rescan)? This activity spinner looks something like like this:

What is the exact info for this album? Have you previously imported a duplicate of it into your database? I ask because it sounds like you performed a library cleanup function, but if there was a duplicate of this album that was inaccessible to Roon (files moved for example) and the previous metadata was associated with the moved album, it is possible that you removed the database entry to the old listing when cleaning the library.

Thanks, Norris,

Here is a screen shot – not sure what is to see there:

By the way, doing this lost 7 albums from my library. They’ll probably return after 4 or 5 more scans.

The album in question is Caroline Scott, “Khoalesce”. I’m not sure if I recently removed a duplicate. It’s from Bandcamp. What you suggest is certainly possible.

If you go to Library Maintenance does anything show up there? (Not suggesting you use cleanup just to see if Roon is thinking the files were deleted, or on missing media, etc)

Hi @ronfint,

Yes, I would check the library cleanup page to see if there are any old entries. I would not run library cleanup but just check the numbers.

Also, have you by any chance rebooted your Core and NAS recently? I wonder if things are in a weird state and need a reboot, you shouldn’t have to scan it multiple times to see the proper albums show up.

One other possibility here is that there is a networking issue and when Roon tries to scan these files the NAS has a temporary issue with the network preventing it from seeing the albums.

If you simplify your network a bit and have both the NAS and Core connected to your router instead, is there any change in behavior?

Thank you for this suggestion. Occasionally after rescanning (almost always 5 or 6 times consecutively) I check this and there a a few files to delete — so I do so.

If there are a few files to delete and you have not deleted anything, then, something is not quite right.

1 Like

I have restarted my core and roonserver several times recently. I can’t connect both my nuc and nas directly to a router because my router does not have enough ethernet ports. I was thinking that I might try to obtain a usb3 to ethernet adapter and then connect my nuc directly to the nas as well as to the switch — but that would make things more rather than less complicated.

One thing that I have noticed at rescans is that the variability in the number of albums and tracks occurs mostly at the beginning and the end of a scan. Could this mean that the problem is with special characters in file names? But that wouldn’t explain why my problem is relatively recent and did not occur before.

Have you thought about just moving your files locally (not on the NAS) to the NUC via an external USB HD. And then just using the NAS as a backup device.

That’s always a possibility, but I have currently between 8 and 9 TB and thousands of LPs yet to digitize. There are some very big usb external drives now, though.

Hmm. Yes, that is quite a lot of required storage.

Hi @ronfint,

What kind of switch are you using, is it managed or unmanaged? Have you still seen this behavior again recently? I don’t think this is an issue with special characters, but possibly something networking related, where Roon tries to scan a media file but the network is unstable and is unable to do so.

Hello Noris,

It is an unmanaged switch. I have exchanged it for another and I have also put new ethernet cables in place of the old ones. And I restarted my nas. It still takes several scans to find all my files, but things seem a little more robust. I’m away for the weekend, but I’ll experiment a bit more next week and report. I appreciate your help.

If this doesn’t help, perhaps it’s time to replace my nas. It’s not inexpensive to do this; so it would be reassuring if there were some way to determine for sure that the nas is what is causing my problem. Might there be cues to look for in my roon logs?

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

NUC7i7DNBE / Audiolinux / Roon 1.6 (build 416)

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Music storage on NAS, attached via ethernet-switch to core

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Roon Endpoint (connected via ethernet switch) / USB to DAC

Description Of Issue
After every restart of my system, Roon scans my library (as expected). But it misses a lot of files. I have to do multiple rescans until roon sees every track in my library. The mising files show up when I go to “Settings/Library/Clean Library” under “clean up XXX deleted files” and NOT “clean up XXX files that are not associated with a storage location”. So Roon sees these files as deleted.
But after 4-5 rescans all files are back. Under “Settings/Storage” the “XXX Tracks Imorted”-Number sometimes goes down instead of up with every rescan. I always rescan until all my files are there. I check with the “XXX Tracks imported”-Number and check if under “Settings/Library/clean Library” there are no deleted Tracks left.

At first I suspected a Hardware failure of the storage SSD in my NAS. I bought a new SSD but the problem continues. I then tried to restore a backup from when the problem didnt exist with no luck. I also removed all filters for skipped files on Roon import. I can mount the Network-Folder just fine and see all files. I also can see them via SSH. Just Roon has a problem reading them. What could be the issue here?

Hi @Toldoe,

What kind of files are missing, are they all one specific media format? Do they contain any special characters in the file name? Please provide a screenshot to the file path of one of these problematic files, you can upload screenshots by using these instructions.

I dont know what these files are since roon doesnt let me view the deleted files in “clean library”.
My library consists of flac and aiff.
As far as I know its random. No special characters. Otherwise roon wouldnt import after multiple rescans?

Hi @ronfint & @Toldoe,

I have merged your reports together since you are both using Audiolinux Cores with very similar symptoms.

Can I please ask the both of you, if you temporarily use another type of Core to host the Roon Core, does this behavior change? My suspicion here is that the AudioLinux Core might have something to do with this issue.


Thanks again. I don’t have anything else available to use as a temporary core. I just did a rescan and again it took 5 more rescans to find all my files. I guess that there could be a problem with the way roon interacts with archlinux, but isn’t it strange that only one other person has reported this behavior?

Could logs help with this? There seem to be a number of “Could not identify” in mine, along with album names.

Yes it seems like we are having the same issue. Roon Core on AL nuc7i7DNBE with music files on NAS…

Just a thought — I think the issue began for me after updating the linux realtime kernel from 4.something to 5.2. @Toldoe is this true for you as well?