@js wrote:
@rpedde wrote:
A regular scan just checks for changed files. If it finds one, it scans it and wipes out the existing database entry (if any) with a new entry. Any files that haven’t changed, it doesn’t touch metadata for.
How does it decide if a file has changed? Does a changed mtime and/or atime count as a “change”? What about permission or ownership change?
Based on mtime, which is file content change. Not atime, which is last accessed time. Otherwise it would reindex every time you played a song. And it doesn’t reindex on permissions or owner change. that’s ctime.
Or that’s the theory, anyway.
I really haven’t been in the position where I would have noticed it if it acted differently. But that’s what the code says it does.
When it’s started, it does a regular scan unless the db schema was updated and it calls for a full scan
So if the schema changes, I’d need to dump the ratings from the database before upgrading, and then re-update the database after re-building it?
I’d like to delete most of the music from my nearly-full ibook drive, and leave firefly as my canonical music library, using iTunes as a mere staging area. Just want to make sure I’m not going to cause myself to lose any ratings in the future! (Ratings are the primary way I “filter” for listening, so it’s very important to me that I don’t clobber them somehow!)
Thanks for clarifying how the scans work.
-Jason
Yes, that’s true. I don’t really know how to handle it better. Maybe I could find a way to dump the metadata that isn’t a part of the tag somewhere. I had thought about it before, and it seemed like the “best” way to do it would be to drop a file next to every media file with the supplimentary info in it — like last played time, play count, rating, stuff that wasn’t part of metadata.
But yuck. What a mess.