[AMoo-Miki]

An automated process dumps all the new audio files downloaded into a common flat folder and asks Kodi to scan it via the JSON-RPC API. The documentation notes that the library update process "only actually scans the tags from those files that are new or changed" but what I have noticed in the logs is that irrespective of any modified time on the files, every audio file in the folder is removed from the library and rescanned.

Code:


NOTICE: Starting Kodi (18.6 Git:leia_pi4_18.6-Leia). Platform: Linux ARM 32-bit
...
NOTICE: Running on LibreELEC (official): 9.2.1, kernel: Linux ARM 32-bit version 4.19.106
...
DEBUG: DoScan Rescanning dir 'smb://Ivan/Music/New Downloads/' due to change
DEBUG: Mysql execute: UPDATE versiontagscan SET lastscanned = '2020-06-15 03:42:32'
DEBUG: Mysql execute: delete from song where idSong in (...4244 of ids...)
DEBUG: Mysql execute: delete from path where strPath='smb://Ivan/Music/New Downloads/'
DEBUG: CSMBFile::Open - opened smb://Ivan/Music/New Downloads/3d..., fd=10000
DEBUG: CSMBFile::Close closing fd 10000
... repeats open and close on all files
... insert song, album, ...


Looking at the database, I see strHash only recorded at folder level and it leads me to believe that this is how audio scanning is supposed to work. Is my understanding wrong, the documentation outdated, LE-flavored-Kodi somehow breaking things, or JSON-RPC's AudioLibrary.Scan not capable of checking for changes at the file level?

[Klojum]

For videos, and I'm assuming for music files as well, changes on file level are not detected as the library update scans are not designed to do that. Only when files are added to the libraries as new files, are they scanned / hashed, etcetera. The library update process would take so much longer if every media file were to be fully x-ray'd for changes. Media files with changed locations are considered new, files with changes in size and/or content alone will not be noticed as such. The wiki documentation may be incorrect at that point.

[AMoo-Miki]

Thanks for the clarification. I should throw them in daily folders to avoid the rescan.

[HomerJau]

I’m sure the music scan finds tag changes for existing files in the music library. Or it did the last time I updated tags and scanned a few weeks ago, Kodi 18.6 probably.

[DaveBlake]

The JSON AudioLibrary.Scan method is the same as clicking "Update Library" on the side blade. Library update recursively loops through the hiercharchy of folders containing the music files previously scanned into the library. Each folder path has a hash value made of timestamp, name and size is stored, the process checks that hash against current folder state and if it is different it loops inside doing the same.

You will see the progress bar update as it loops superficially examining hash values for every folder, and only actually scanning the tags embedded in music files in folders where the hash for the folder has changed. Kodi uses a delete/insert approach to such changes.

If you edit a music file then the hash value of the folder it is in will be changed, all the music files in that folder then get rescanned in depth. So in a completely flat system, adding new files will mean that all the files will be rescanned when library update is called,  and a lot of database records will be deteled and recreated.

Via GUI you can navigate into subfolders and trgger scanning of just those instead of checking the hash of every path.

[HeresJohnny]

An automated process dumps all the new audio files downloaded into a common flat folder

If banned add-ons are grounds for refusing support, that phrase should trigger even more concern...

[black_eagle]

If banned add-ons are grounds for refusing support, that phrase should trigger even more concern...

Nobody mentioned any add-ons.  Buying and then downloading music is a thing, isn't it?  eg 7digital, itunes, Amazon etc