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

Maybe the issue existed for some time before I noticed. I cant remember a specific update or modification that lead to this problem.
If I find time I might give euphony a shot. I wanted to try it out anyway. If AL is the issue, maybe a different OS might fix it.

1 Like

Hi @ronfint,

I discussed this issue with QA and we have seen similar behavior in the past it was either due to the NAS, the Core or the Network and in their experience logs look as expected so I donā€™t think it would be of much help.

We should try to isolate the Core from this issue and my suggestion would be to try a different OS as @Toldoe suggests. One other thing that may be a useful test here would be - instead of performing the rescans immediately, what happens if you wait for a bit of time and then perform one single rescan, do all the albums show up then?

With this test in mind we are trying to see if there is a delay before the Core is able to see all the albums and just one rescan is needed but there is a delay before it is able to properly communicate with the NAS.

Still, my first suggested test here would be to try a different OS since your two reports are the only ones I have recently seen and they both use AudioLinux Cores.

I have been in contact with AudioLinux, and their suggestion is

  1. System update (before was update all other packages)
  2. Roon update (this is because roon is distributing the linux package without build number)
  3. Update kernel
  4. Select Clean on the main menu
  5. Reboot

I followed this advice, and it helped significantly. During rescans the oscillation is now quite controlled varying in a range of <= 5 albums, and it becomes stable after an extra rescan or so. I have also found a few more albums than I was able to find before.

I will try your rescan test a little later, but for now, I think my system is at least usable once more.

Here is a solution to this problem ā€“ I think. It turned out that the steps outlined above did not do the trick. There was still some instability on rescans. So I downgraded my linux kernel to v.4.19. Everything is now very stable (as it used to be). So if anyone else (@Toldoe) is having this problem, I think that the answer lies in downgrading the linux kernel.

Experts at roon (@noris) probably should be asking why linux v.5.2 is causing problems with roon library scans.

Hi @ronfint,

Glad to hear that things have stabilized since downgrading the kernel version. I canā€™t comment on what kernel changes have been made to AudioLinux and how they impact Roon scanning behavior but I have forwarded your findings to our technical team. Thanks again for the report.

Thanks very much, @noris. I just want to clarify one point. The kernel versions that I am speaking of are not specific to AudioLinux software, but are linux kernel versions and apply to all linux based systems, even presumably ROCK should it upgrade to the latest kernel.

I too was able to resolve the bug. Like recomended, I installed euphony os on my core nuc. Now it scans my library flawlessly. Not sure but i think euphony is also archlinux based, but I dont know what kernel is used in this os. Might be woth noting that there are issues with some kernels and roon.
Anyway, im glad we could figure this out eventually.

Hi @ronfint,
Thanks for clarifying the kernel version further, I have added this as a note to this case.

@Toldoe,
Glad to hear that euphony is working as expected on your end!

OMG thank you guys! Installed Audio-Linux yesterday and even restoring a week old database ā€¦ it was messing upā€¦ rescanning everythingā€¦ very annoying.

Just did the downgrade to 4.19 and fixed the problem.

I hope that Roon is looking into its compatibility with Linux 5.x. Iā€™m still on 4.19 because of this scanning issue.

1 Like

Anybody updated Roon 1.7 + Linux 5.x ???

Yes, problem still exists.

Euphony 3.0 still uses 4.19 hence no problem.

@noris, There are now several instances of this compatibility issue of roon with linux firmware 5.x. Can you please confirm that roon is thinking about/ working on solving this problem?

Thanks,
Ron

Hi @ronfint,

Yes, we are working on this issue. It took a bit of time until we were able to request a copy of AudioLinux, but the investigation is still underway and itā€™s currently with QA to reproduce and file a report for the devs.

Thanks very much. Iā€™m glad to hear this.

1 Like

Hello, any updates on this topic. It is the same problem with gentooplayer and 5.x kernel.

Hi @Patatorz,

I just spoke to QA regarding testing this kernel version and itā€™s very close to the top of their to-do list.

Apologies for the delay here, there have been a few higher-priority hardware issues which needed to be investigated before this issue could be looked at.

@noris thanks a lot for the follow-up. No problem just to be sure it would be in the list. I moved back to kernel 4.19. ANyway it is not only a audiolinux topic but more a kernel 5.x issue.

Was not in the 528 build. Letā€™s hope for next one :slight_smile:

1 Like

Hello All,

I just spoke to QA and we attempted to reproduce these findings on Ubuntu with 5.3.0-40-generic and we havenā€™t been able to sucessfully reproduce this with the 5.X kernel so far. Can you please let us know:

  1. What is the exact Kernel version of those affected by this behavior?

  2. What are the formats of albums affected by this issue? Are they all FLAC/AIFF/MP3 or a specific format or does the format not appear to be related?

  3. If you edit the tags for any album affected by this issue, does Roon immediately rescan the album and apply the changes when using the 5.X kernel?