What would such a clean up do which the regular scan shouldn't already
be doing?...
It was just an idea to keep the "new&changed" quick (and I like it to be
this quick ;)) to "outsource" options like looking for orphaned entries
in a separate routine You only use once a week or once a month... (the
"n&c" I use daily).
You're one of the multi 100k tracks guys, aren't you? Would you mind
sharing a (compressed) copy of your library.db which is in a "has empty
artists" state?
https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a
I wonder whether a simple SQL query could cure this particular problem.
OK, for now I have 3 main issues (I started to look into the sqlite
myself to get some "idea" where they result from, but I'm really not an
expert ;-))
Please create tickets on Github for the actual bugs. Thanks!
1. Artists without any tracks in the database are still listed and still
linked to their "old" entries
The problem here being that the artist is listed even though it's only
there as a "secondary" contributor, not to be listed?
3. Adding tracks to an existing albums result in two albums of the same
name
(Happens when You add tracks from a deluxe edition e.g.:
- Standard edition is in database (one album, 10 tracks) => all fine
- You add track 11-13 from the deluxe edition: SAME (windows) folder,
SAME album name, SAME year, SAME album artist, SAME compilation tag
eg...) => You have TWO albums of the same name and artist in Your db,
one with track 1-10 , the other one with track 11-13)
This IMHO would only happen if the tracks were stored in different
places, if the titles differed (eg. due to the appended "deluxe
edition"), or if some musicbrainz ID was different. Please double and
triple check that this is not a tagging issue. Would a wipe & rescan
overcome this issue? Here again a copy of a libary.db in this state
could be helpful.
_______________________________________________
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
