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

Hello @noris,

In my scenario :

  1. I guess any 5.x version. In my case linux-rt-5.4.10.5-1
    Remember that Audio-Linux uses ArchLinux as OS not Ubuntu.

  2. Any. .dsf, .flac.

  3. I didn’t try that. What happens is that everytime I do a “Force Rescan” … some albums disapper from the Roon Library. The number of albums on the top of the window change significantly. For example … I have right now 9200 albums. When I rescan the library it changes to 8745. When I do it again, it goes to 9107… and so on. Randomically. I can’t find a reason or a pattern for this behavior.

BTW, I already tried restoring the database from a week ago. When the restore process finish, it shows less albums than before. Same random behavior. Also tried building the library from scratch removing all storage settings and entering again etc … same thing.

Thanks.

1 Like

Has the team tried to reproduce the issue with the library on a Synology NAS? Mine’s an 1813+. As fscheiner says, any linux firmware 5.x causes the problem. Also, it seems to be independent of file type. My files are mostly ALAC.

Hi @fscheiner/@ronfint,

Thank you for the additional information.

The copy of AudioLinux that we were able to source is unfortunately with an older kernel version, so it won’t be too helpful. The environment that we have tried to reproduce so far is on Ubuntu 19.10 with kernels 5.3.0/5.4.10/5.4.11/5.5.9 and on Arch-linux with kernel 5.1.4.

We have had no success so far but there has been one difference here, in that we do not have a NAS in this specific QA lab, so we have been attempting to test for this behavior by using Windows shares over the network.

Can I please ask - if either of you happen to have a Windows machine in your setup, could you please try setting up a small media share and verify if the same behavior occurs when you use the 5.X kernel and try to scan a Windows share?

I’m sorry, I don’t have a Windows computer, but in AudioLinux, it’s easy to update the kernel using the menu. If you have problems, I’ll be glad to help, or you could contact Piero.

1 Like

Same problem whatever the format with kernel 5.x (linux-rt-5.4.10.5-1 in my case) on audio-linux (archlinux base) and gentooplayer (gentoo/debian base).

No windows machine…

1 Like

@noris, i’m sorry but I don’t have any windows machine in my setup. Please contact Piero from Audio-Linux, i’m sure he can provide you instructions to upgrade kernel to 5.x.

1 Like

@noris Has there been any progress on this issue?

I’m sure that all of us who are affected are happy to help in any way. I’d really like to be able to update my Linux firmware.

@noris. Build 536 does not solve this problem. (And it did not claim to.) I hope that soon we will be able to update linux firmware without roon scanning problems.

Hi @ronfint,

I’m meeting with QA later this week to discuss this case, build 536 didn’t have any progress towards this issue, but I’m hoping to make another push for QA to test this behavior further, I will let you know once I have had a chance to discuss with them, thanks!

@noris Thanks very much. I appreciate any help you are able to provide.

@noris Just one more bit of information. After upgrading to build 536, I upgraded my Linux firmware to the most recent version, but I experienced the loss of many albums upon rescanning. I then downgraded to Linux 4.19.x. The scanning problems became less severe, but did not become completely stable as they had been before 536. I now need to rescan several times to recover all my albums. The swings have been as great as 20 or 30 albums.

Addendum: After a bit of time, all is a bit more stable with Linux firmware 4.19.x and build 536. Swings are +/- 10 to 15 albums.

Hi @ronfint,

I just wanted to update you here and let you know that I have spoken to QA and they plan to reach out directly to Piero to see if we can get a copy of Audiolinux with the new Kernel for testing.

@noris Thank you, however, contacting Piero for this is unnecessary. I thought you already had a copy of AudioLinux. The kernel can be easily updated using the menu. This takes just a couple of clicks.

Also, I want to update my comments about the current stability of rescanning with my setup and Linux firmware 4.19.x. It is frustratingly unstable. In order to see if something was wrong at my end, I restarted my Synology NAS and rebooted my Roon core. The result was the loss of a hundred or so albums. It took me 5 more rescans to get most of the albums back. I decided to stop when I was 3 shy of my previous “stable” number.

Would it help if I took an iphone video of my screen as a rescan was in progress?

It’s really getting out of hand, even with the old Linux firmware 4.19.x and Roon build 537. Last night while Roon was making a backup it lost around 50 albums. This morning it took 4 or 5 rescans to gain (most of) them back.

To everyone who is having trouble with this rescanning issue: Here is something to try.

I spent the morning experimenting with different kernels in Audiolinux. I first did a complete system update and then updated the Audiolinux menu to current (217). Following that, I updated the kernel. When doing this, one is given three choices 1. Audiolinux RT, 2. Audiolinux RT BFQ, 3. Audiolinux RT BFQ 4.19.x.

I had been using option 3 as a stable option for quite a while, but it lost stability with Roon build 536 (and 537). Likewise option 2 is completely unstable. However option 1, Audiolinux RT, is stable. I have rescanned several times, and my number of albums has remained constant (and correct).

My recommendation to anyone having Audiolinux rescanning problems is to try the non-BFQ kernel. I will repost in case instability arises again.

@noris So here is a question for QA, “Is there an incompatibility between Roon and the Linux BFQ scheduler?”

Hi @ronfint,

Noris brought this to our meeting and I wanted to reach out to you about this. I’m happy to hear that things work when you’re using the non-BFQ kernel. As for why the BFQ version doesn’t work with Roon — We asked our QA team and there is nothing that they’re aware of that would cause an issue. Our advice is to reach out to Audiolinux directly and they should be able to provide insight here and help to clarify whether or not that kernel might work for you.

Thanks!

Besides 5.x not finding all albums or forgetting and re-finding at startup,

I’ve been running 5.x BFQ without issues for 6 months. Stable as can be. I’ve also run 5.x RT and 4.19 RT without issue. Or to restate, both version of 5.x have scanning issues while 4.19 BFQ does not, otherwise all are stable, I prefer 5.x BFQ sound presentation.

Linux pinkfaun 5.4.19-rt11-1-rt-bfq #1 SMP PREEMPT Sat, 15 Feb 2020 07:17:27 +0000 x86_64 GNU/Linux

Followed @ronfint instructions and updated Kernel option 1 - Audiolinux RT (default).

After reboot, uname -r now shows 5.6.10-rt5-2-rt.

Rescan issue solved and system is now stable.

Thanks so much for all efforts involved.

2 Likes

Will give this audiolinux kernel a try on my ‘test NUC’. My main system is currently running roon on Win10 LTSC because of these problems. My newly installed ubuntu 20 LTS was continuously dropping albums during rescan’s so… that messed up my library pretty badly in the end (before I discovered this I also had library backups with missing albums).