Core Machine (Operating system/System info/Roon build number)
Roon 1.7 on Linux
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
not relevant for this issue
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
not relevant for this issue
Description Of Issue
In the past we were using kernel 4.1.13-rt15-1-rt with Roon and this started to give problems when Roon released 1.6. Roon could not reproduce our issue, but they were not using this specific kernel.
We have strong reasons to believe this kernel which was also used by Euphony and which was open sourced on the Arch Linux forums, corrupts the data under high IO load, as we found evidence of this on a test system during a file copy. We could reliably reproduce this data corruption issue in the lab.
A not so elegant but working solution, is to boot with a newer 5.X kernel which does not have these data corruption issues, stop Roon, wipe /root/.RoonServer and /root/.RoonGoer, start Roon and all the issues we had in the past since Roon 1.6 are gone. But then the customer has to go through everything once again, and playlists are gone.
However, when users with a corrupted database boot with a more recent kernel that does not corrupt the data, Roon once again becomes slow, as the data was already corrupted by the previous kernel.
So we want to be able to completely rebuild the Roon folders from scratch, but keep the playlists. I know there is a feature in Roon to export the playlists to .m3u, but those all contain relative paths.
When we then place the m3u file back into a storage folder it does not look like it’s being picked up.
So the main question is: how do we completely begin again from scratch (let Roon index from scratch and not use any previous database) while maintaining the playlists?