Scan results can vary depending on how scan is initiated (?)

[jim_hamilton]

Roon Core Machine

ROCK on intel NUC 10i

Networking Gear & Setup Details

Not Relevant

Connected Audio Devices

Not Relevant

Number of Tracks in Library

Not Relevant

Description of Issue

How Scan works:
I’ve written about this before, but got no response from roon support personnel. While I have not done exhaustive testing, I believe scan works differently in these 3 situations:

1. run a scan on demand from the roon interface (storage/scan now)
2. automatic scan after roon server software restart (from web interface)
3. automatic scan after roon server reboot.
   (not as sure 2 and 3 are different from each other).

I believe this deserves a knowledge base article on scan, at least I can’t find any such information.
In the past with metadata changes, and this week with playlist edits, I think I got nailed with this.

I did a roonOS reinstall on my NUC, and after having trouble with backup restore (separate post), needed to reload my externally generated m3u playlists (which I previously created outside roon and imported. I exported them prior to the reinstall, so otherwise they would have been lost since backup restore did not work. When you export a playlist as .xls, the spreadsheet shows roons path, not the path originally specified in the imported m3u file).

I did a quick refresh on playlist import (roon knowledge base), but no matter what path I tried, the playlists did not show up after a scan (scan type 1 above, on demand scan). (the knowledge base article on playlist import could be improved by giving some examples, its a bit vague on how to specify track location for m3u playlists. In my case, all my music is on an NFS/SMB server on my local subnet, in a folder called “music”, simple genre/artist/album filestructure. a typical m3u playlist entry that works for roon is then …/jazz/ArtBlakey/1959-Moanin-HDR-DSD64-9CC/01 - Moanin’.dsf).

At some point I rebooted the server. voila, all my m3u playlists showed up. so scan types 1 and 3 can have different effects, or so it would appear from this test. I think what happened was this: I initially used an incorrect path in the m3u’s I wanted to import (no clear example in the knowledge base article). When I corrected the paths and rescanned, I suspect an on-demand rescan is not thorough for performance reasons, saw the same m3u filename, and did not analyze further/look at modified date. The reboot scan was more thorough (my hypothesis).

I have previously seen (and posted) differences in whether metadata changes outside roon are recognized by a scan, depending on the scan type (1,2,3 above). Messy and timeconsuming for a user to test. Roon never confirmed nor denied differences.

So, @support:

• am I correct that the 3 ways of initiating scan listed above can give slightly different scan depths?
• could roon consider a couple of knowledge base improvements? the forum is great, but for specifics the signal/noise ratio can be daunting. Specifically:

1. provide examples of path specification in the KB article on m3u track paths, don’t just say ‘match fileinfo’.
2. If I am correct that scan can be slightly different for some corner cases like some metadata changes and m3u file path specification changes, please consider a new KB article better explaining scan.