Bugzilla – Bug 17274
Scanner indicates new files if there are m3u files in music folder
Last modified: 2011-09-05 18:17:59 UTC
In a setup where "Music Folder" and "Playlist Folder" points to different directories, the scanner always indicates new files if there are m3u files in the "Music Folder". The issue is that the scanned_files table contains these m3u files while they are never written to the tracks table, so the check in Slim::Utils::Scanner::Local::rescan that verifies if there are any changes will always indicate that there are new files. This will result in that a scan for new/changed files will take longer time even if there aren't any new/changed files. I haven't verified if it also affects the auto scanner, or just the new/changed scans indicated from the user interface. Besides this it will also result in that third party scanners and third party client which checks the Slim::Music::Import->lastScanTime will be tricked into thinking that there are changes when there aren't. It's pretty usual that a ripping program puts a m3u file into each album folder during ripping, so this might be a problem for many users, especially the issue that it triggers an update of Slim::Music::Import->lastScanTime.
Voted , this migth expain the anomaly where sbs always finds 67 new files or so every time you scan ? This count have "always" deviated from the true number of new tracks ? ( or have so for a long time lately)
(In reply to comment #1) > Voted , this migth expain the anomaly where sbs always finds 67 new files or so > every time you scan ? This count have "always" deviated from the true number of > new tracks ? ( or have so for a long time lately) I don't see anything like that behavior. If you're seeing this then it would seem that there's a bug in how SBS is detecting changed files. There is a small anomaly seen in the web interface's scanning details, though. When doing a new & changed scan it always shows one new file being scanned, even when there are zero. My guess is that this was a simple hack to get the progress bar to display, otherwise it wouldn't be shown.
Same problem detected here (Linux, Debian Lenny). Always finds new files on rescan although nothing was changed. Reason is here .m3u-files in the music-directory, too.
Same problem here under Fedora 14 (Vortexbox). Vortexbox automatically creates a playlist of every CD it rips and places it in the same folder as the corresponding flac files. These keep being seen as new files but since they are never added to the database, they are perpetually new files whenever a rescan is done. I'm curious as to what the scanner can usefully do with these playlist files that are not stored in the playlists folder? I.e., why are they not ignored altogether?