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.
This new option allows users to provide a list of external config files
which will be evaluated when beets starts.
This is useful for keeping private settings (e.g. API keys) out of the
main configuration file.
interactive_open should now be invoked with at least the list of
targets and optionally the command to open the targets with.
This allows beets-play to pass multiple file paths directly to
the configured command.
The changes to the existing invocations are pretty trivial in
order to comply to this refactor.
This method already groups reading the config, managing file I/O
and exceptions, as well as sending events to the plugins, so it's
really easier and cleaner to do it that way. Note that passing
'images':None as tags to update correctly triggers beets to delete
the images tag altogether.
For example, this led beets-check to not recompute hashes when
doing beet clearart [query]. Further operations on the file(s)
would then trigger beets-check to issue integrity warnings.
