MrSinatra;578016 Wrote:
> but thats my question... if you can find all the changed files, then
> why not rescan the entire file/tag, treat it all as a new record, and
> then delete the old record as a case where that file no longer exists,
> (at least, not in the same form)?
>
> why try to figure out what part of the record is different?
It's the age old problem of stale data. The database isn't completely
normalized. To do so would make some operations painfully slow, such
as gathering up a list of albums by a certain artist based only on the
tracks table. So there are tables in the database for things like
albums, artists, genres and years that are very dependent on the data
for the tracks in the library. When a track changes you may have to
update one or more of those other tables.
When the discnumber mistake caused 15 albums to be created, there were
now 15 albums, each associated with one of those 15 different tracks.
After rescanning those tracks a new album was constructed (or one of
the 15 was used) that consisted of those tracks. But that leaves 14
other albums now with zero tracks. You have to either:
- After a track is rescanned,
- If the album changed, check the old album to see if it still is
used by any other tracks. If not delete the old album.
- If the genre(s) changed, check the old genres to see if they
still are used. If not, delete them.
- If the artist(s) changed, check and delete the artist if the
artist no longer has any tracks in the database.
- If the year changed, check and delete the year if it's not longer
used by any album.
- Do the above in several database 'consolidation' passes that remove
stale data and ensure the integrity of the database.
I think the second approach has been used in the past, but I don't like
it for a couple reasons. The main one is that if the scan is aborted by
either the user or an error then you're often left with stale data.
The first can be tedious to program because you when you see a changed
track you have to save the old metadata, including all dependencies and
then after rescanning the track and getting the new metadata, compare
them and recognize which dependent records might now be abandoned.
Then you check those dependent records to see whether they're still in
use. It's also slow to perform all of these tasks on a track-by-track
basis, but since it's only done for changed tracks you can usually live
with it, as people should only rarely be changing many tracks at a time.
--
JJZolx
------------------------------------------------------------------------
JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
View this thread: http://forums.slimdevices.com/showthread.php?t=82096
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
