Doing some testing and found the following, which seems like a bug:
System: Win7 x64
XBMC Frodo 12.1 and Gotham 13.A2 0329 (portable mode)
Configuration:
Created a single local folder with several music song files. Added the folder as a music source and scanned into library. All files scanned into the music library database and textures cached confirmed by reviewing MyMusic32.db and textures13.db.
Test:
Deleted 2 files from the source folder.
Started XBMC.
Performed a library clean, confirmed songs were not in library and exited.
Verified cleaned from MyMusic32.db.
Replaced the 2 files previously deleted from source folder
Started XBMC and did a scan of music source. No songs added to database. Exited
Verified not added in MyMusic32.db and log showed CMusicInfoScanner exited due to
"DoScan Skipping dir ... due to no change"
Repeated test. This time after deleting the 2 files and performing a library clean, I did a scan of the music source. This time CMusicInfoScanner did run (though of course no change to the database).
Now when I replaced the 2 files previously deleted from the source folder, restarted XBMC and did a scan of the music source, the scanner did run and pick up the 2 replaced files (confirmed in MyMusic32.db).
Analysis:
IIUC, CMusicInfoScanner computes a hash of the folder and filenames when doing an update. The hash is saved and compared when a subsequent update is requested. ISTM that after a database clean operation, the existing hash is retained. If the file contents are then restored so the newly computed hash is identical, the scanner misses the change.
I don't know what the requirement is, but this seems incorrect. I would expect that if the database is cleaned, the hashes would be reset/nulled, at least for any folder in which the clean resulted in removing songs from the database. As it is, the work-around of doing a library update immediately after doing a clean could be confirmed and published as a way to avoid this problem.
I did see a ticket 13504 on Trac which seems sort of similar, though that one is for video database ("cleanonupdate" may be involved on that one and AFAIK that isn't available for the music db).
scott s.
.
System: Win7 x64
XBMC Frodo 12.1 and Gotham 13.A2 0329 (portable mode)
Configuration:
Created a single local folder with several music song files. Added the folder as a music source and scanned into library. All files scanned into the music library database and textures cached confirmed by reviewing MyMusic32.db and textures13.db.
Test:
Deleted 2 files from the source folder.
Started XBMC.
Performed a library clean, confirmed songs were not in library and exited.
Verified cleaned from MyMusic32.db.
Replaced the 2 files previously deleted from source folder
Started XBMC and did a scan of music source. No songs added to database. Exited
Verified not added in MyMusic32.db and log showed CMusicInfoScanner exited due to
"DoScan Skipping dir ... due to no change"
Repeated test. This time after deleting the 2 files and performing a library clean, I did a scan of the music source. This time CMusicInfoScanner did run (though of course no change to the database).
Now when I replaced the 2 files previously deleted from the source folder, restarted XBMC and did a scan of the music source, the scanner did run and pick up the 2 replaced files (confirmed in MyMusic32.db).
Analysis:
IIUC, CMusicInfoScanner computes a hash of the folder and filenames when doing an update. The hash is saved and compared when a subsequent update is requested. ISTM that after a database clean operation, the existing hash is retained. If the file contents are then restored so the newly computed hash is identical, the scanner misses the change.
I don't know what the requirement is, but this seems incorrect. I would expect that if the database is cleaned, the hashes would be reset/nulled, at least for any folder in which the clean resulted in removing songs from the database. As it is, the work-around of doing a library update immediately after doing a clean could be confirmed and published as a way to avoid this problem.
I did see a ticket 13504 on Trac which seems sort of similar, though that one is for video database ("cleanonupdate" may be involved on that one and AFAIK that isn't available for the music db).
scott s.
.