Return one valid genre even if its weight is lower then ```min_weight```.
Default for ```min_weight``` is now *10*.
Added new config option ```max_genres``` to limit the amount of genres returned. Default is *3*.
These config options make it easier to customize the command (no need to make
a single-element formats dict). And the opt config option provides backwards
compatibility with the previous style.
The format key is now the (lower-cased) format name string used by beets,
which means we can precisely detect which transcodes would be unnecessary. To
facilitate this, I added an ALIASES dict which allows more convenient names to
work for this (e.g., "wma" is easier to remember than "windows media").
This allows you to use a socket in your home directory (e.g.
`~/.mpd/socket`) without having to specify the full path including the
username (which can change from machine to machine).
In preparation for enabling queries over flexattrs, this is a new path that
lets queries avoid generating SQLite expressions altogether. Any query that
can be completely evaluated in SQLite will be, but when it can't, we now fall
back to running the entire query in Python by selecting everything from the
database and running the `match` predicate.
To begin with, this mechanism replaces RegisteredFieldQueries, which
previously used Python callbacks for evaluation. Now they just indicate that
they're slow queries and the query system falls back automatically.
This has the great upside that it lets use implement arbitrarily complex
queries without shoehorning everything into SQLite when that (a) is way too
complicated and (b) doesn't buy us much performance anyway. The obvious
drawback is that any code dealing with queries now has to handle two cases
(slow and fast).
In the future, we could optimize this further by combing fast and slow query
styles. For example, if you want to match with a substring *and* a regular
expression, we can do a first pass in SQLite and apply the regex predicate on
the results. Avoided for now because premature optimization, etc., etc.
Next step: implement flexattr matches as slow queries.
An earlier change (due to @pedros) added the ability for plugins to define
template fields that work with Albums as well as Items. This enables some
cool new use cases but required that every template field definition check the
type of its arguments. Instead, this iteration on the idea distinguishes
between fields meant for Items and those meant for Albums.
In addition to simplifying the implementation of these functions, this also
enables the creation of album fields with identical names to item fields.
(For example, a user contacted me recently about adding a $bitrate field for
albums, which would be the average bitrate of the items. They can do this now
using a plugin.)
I also changed the docs to stop using the decorator approach to registering
template fields. We're moving toward removing those.
I thought having "MusicBrainz" colored green was a little distracting since
it's the common case (and universal without the discogs plugin), so this just
makes it neutral-color in that case.
This is a refactor of the plugin developed by `imenem`.
- Pass `artist`, `album` and `va_likely` to `candidates()` so that
plugins don't have to work this out from `items` all over again.
- Pass `artist` and `title` to `item_candidates()`.
- Silence spurious `urllib3` info log lines.
- Use a proper "beets" user agent with `discogs_client`.
- Remove `abstract_search` plugin. It seems unnecessary. How many
music databases are there? How many will beets support? How much
common code might there be between them? We can add some abstraction
if or when more databases are supported.
- Derive more AlbumInfo and TrackInfo properties from discogs Release
objects, especially album ID so that beets doesn't just use the first
release and think all subsequent releases are duplicates.
- Add basic documentation, doc strings and code comments.
- Sanitise search query. Remove non-word characters and medium info that
might filter out good search results.
- Use artist `join` strings from discogs Release object when an album
or track has multiple artists.
- Don't rely on discogs track position, which is unreliable. But tracks
are in order, so we can recalculate medium and medium_index as long as
we can extract a consistent medium across tracks from the position.
- Add "various" as a known signal to indicate various artists.
- Prevent `chroma` plugin from returning a a huge track distance for any
track that is missing an ID (e.g. all discog tracks).
- `TrackInfo.index` should be the release index (calculated by beets),
not the medium index (derived from discogs track position).
- Add `AlbumInfo.data_source`. It's "Unknown" by default which is shown
in red when displaying a suggested or selected match. The built in
auto tagger sets it to "MusicBrainz" which is shown in green. Anything
else (e.g. "Discogs") is shown in yellow.
- Remove double spaces from album titles (bad data from Discogs).
- adds another traversal through all plugins' template_fields for each
'evaluate_template' call.
- requires the following idiom (or equivalent):
@Plugin.template_field(field')
def _tmpl_field(album):
"""Return stuff.
"""
if isinstance(album, Album):
return stuff
Reading the fetchart docs it was not clear to me that it would use _any_
image file found alongside your music files, even if the image file did
not have one of the five privileged names (cover, front, art, album,
folder). I humbly propose these edits to the docs in an attempt to make
it more clear that, by default, any local image file will be used.
I also corrected '"album," _for_ "folder"' to '"album," _or_ "folder"',
and from reading the code I'm pretty sure that remote_priority needs to
be true, not false, in order to prefer remote sources.
Add a 'fallback' option to facilitate working around the 100 queries/day google
limit by marking files as 'visited' so they are not considered for lyrics search
on the next beet run.
I've put my own google_engine_ID as default value in the code but could be
reconsidered, this engine contains databases known to be scrappable by the
plugin algorithm though.
