Fixes#1264: When a re-import triggers fetchart, the existing album art is no
longer resized if it already has the correct dimensions. This avoids creating
new album art files with unique filenames ("cover.n.jpg").
Should fix#1662.
I think the fix is easy. Don't know if it's clean though. Did some tests (+/- 10 albums), all successful. This is the first time I'm using python so please let me know what I should improve:)
… and move relevant genres from the tree to be children of the `reggae`
top-level genre as well as add `roots reggae` to the list.
See discussion at https://github.com/sampsyo/beets/issues/1661
This was used since time immemorial to keep track of recently-imported music
that hasn't hit the database yet. I created it when the importer only added
music to the database at the end of the pipeline, after doing all the work to
manipulate the metadata. Now, for several reasons, we add the music
immediately after the user sees it and then manipulate the records *in the
database*. With the latest change, which gets rid of the last separation
between UI and database-adding, we no longer need to do this.
It's cheaper and easier to just apply metadata in the UI thread. The
advantage, then, is that we no longer need to keep track of anything in-memory
to enumerate data that has been seen by the user but not added to the database
yet!
In the next step, I'll remove `seen_idents` altogether.
This should fix#1652, which found that this code did the wrong thing when
there were *no* `found_duplicates`: that is, when the duplicate actually came
from the `seen_keys` list, so the album is not in the database yet. This
handling was confusing "no non-empty duplicates" with "no in-database
duplicates", and incorrectly bypassing the duplicates prompt.
Since having empty albums in the database is a rare case (it should be
impossible!), and we should no longer *crash* when it happens, I am
considering it unnecessary to handle it specially. The user will now just see
"Old: 0 items" and that's that.
