This PR fixes a bug (#3834) where tracks which have already been fingerprinted do not return to be used by `beet submit` (part of the Chroma plugin). This results in submission errors, as the fingerprint is omitted from the resultant payload sent to acoustID.
Since pyacoustid returns the fingerprint as bytes (and thus causes the
database to store a bytes/BLOB object), but the tag value is a string,
the acoustid_fingerprint tag always causes file change when using beet's
"write" command, even if the actual value didn't change.
Issue #2942 describes the problem.
This commit fixes that issue for newly imported/fingerprinted files. However,
you still need to change the type of all acoustid_fingerprint fields
that are already present in the database:
$ sqlite3 beets.db
SQLite version 3.26.0 2018-12-01 12:34:55
Enter ".help" for usage hints.
sqlite> UPDATE items SET acoustid_fingerprint = CAST(acoustid_fingerprint AS TEXT);
Uses
match:preferred:countries/original_year:
config options to determine whether the releases should be sorted by their respective fields.
The behaviour is the same as before when the default config is used.
Delete the remaining usages of BeetsPlugin.listen().
Since BeetsPlugin.listeners are wrapped by a loglevel-setting function,
we cannot easily check their unicity anymore.
BeetsPlugin._raw_listeners set holds the raw listeners.
Legacy plugins that did not handle enough arguments in their listenings
functions may break: dedicated code is now deleted for it would not work
with the decorated listeners.
Tests got fixed. Some modifications were done empirically: if it passes
then it's okay.
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
The logger is passed as an argument to multiple function. This showcases
the second possibility for using the new logging system. Several similar
conversions to be expected.
Many commands and plugins use `item.write()` to update tags. Since the success
of the call is not critical to the functionality of most consumers we want to
catch any exceptions, log an error and continue with our task. The new method
encapsulates this logic.
This fixes#675.
The new Distance object knows how to perform various types of distance
calculations (expression, equality, number, priority, string).
It will keep track of each individual penalty that has been applied so
that we can utilise that information in the UI and when making decisions
about the recommendation level.
We now display the top 3 penalties (sorted by weight) on the release
list (and "..." if there are more than 3), and we display all penalties
on the album info line and track change line.
The implementation of the `max_rec` setting has been simplified by
removing duplicate validation and instead looking at the penalties that
have been applied to a distance. As a result, we can now configure a
maximum recommendation for any penalty that might be applied.
We have a few new checks when calculating album distance:
`match: preferred: countries` and `match: preferred: media` can each be
set to a list of countries and media in order of your preference. These
are empty by default. A value that matches the first item will have no
penalty, and a value that doesn't match any item will have an unweighted
penalty of 1.0.
If `match: preferred: original_year` is set to "yes", beets will apply
an unweighted penalty of 1.0 for each year of difference between the
release year and the original year.
We now configure individual weights for `mediums` (disctotal), `label`,
`catalognum`, `country` and `albumdisambig` instead of a single generic
`minor` weight. This gives more control, but more importantly separates
and names the applied penalties so that the UI can convey exactly which
fields have contributed to the overall distance penalty.
Likewise, `missing tracks` and `unmatched tracks` are penalised and
displayed in the UI separately, instead of a combined `partial` penalty.
Display non-MusicBrainz source in the disambiguation string, and
"source" in the list of penalties if a release is penalised for being
a non-MusicBrainz.
As outlined in #299, we broke many places in the code that were expecting
_album_for_id and _track_for_id to return a single item rather than a list. I
took this opportunity to divide up the interface: there's now one function for
MBIDs (returning a single object or None) and one for generic IDs (returning a
list).
It's possible that these plugins might require a little more thought
into how they should work (or not work) with potentially multiple albums
matching an idea, and potentially those those albums being an incorrect
match (e.g. if two data source plugins share a simple numerical ID
format).
