Comment 4 for bug 905669

I believe the original bug was intended to store the mtime with the file info in the database (probably in the track_locations table), so that once we've determined there's been a change in a directory using the hashing method, we can more quickly rescan that directory, by not loading and checking the id3 of each track in that directory if the mtime is the same.

The fix suggested by Ryan in #3 is for a slightly different issue, which is that we don't check the mtime of the files when deciding to do a directory rescan, so if a file changes(for example, changing the id3 tag) but the filename itself doesn't, then the directory won't be scanned.

I have attached a patch which fixes this issue, but doesn't fix the original issue of slow rescan times. Can someone confirm whether or not we want to fix the original issue of slow rescan times?