The data_source penalty was not being calculated correctly because
`_get_distance` was being called for **all** enabled metadata plugins
which eventually meant that matches were being penalised needlessly.
This commit refactors the distance calculation to:
- Remove the plugin-based track_distance() and album_distance() methods
that were applying penalties incorrectly
- Calculate data_source penalties directly in track_distance() and
distance() functions when sources don't match
- Use a centralized get_penalty() function to retrieve plugin-specific
penalty values via a registry with O(1) lookup
- Change default data_source_penalty from 0.0 to 0.5 to ensure
mismatches are penalized by default
- Add data_source to get_most_common_tags() to determine the likely
original source for comparison
This ensures that tracks and albums from different data sources are
properly penalized during matching, improving match quality and
preventing cross-source matches.
## Description
Adds line block markup to example substitutions in the plugin
documentation, so that each case is shown on a separate line:
> The replacement can be an expression utilising the matched regex,
allowing us to create more general rules. Say for example, we want to
sort all albums by multiple artists into the directory of the first
artist. We can thus capture everything before the first ,, `` &`` or ``
and``, and use this capture group in the output, discarding the rest of
the string.
>
> ```yaml
> substitute:
> ^(.*?)(,| &| and).*: \1
> ```
>
> This would handle all the below cases in a single rule:
>
>> Bob Dylan and The Band -> Bob Dylan
>> Neil Young & Crazy Horse -> Neil Young
>> James Yorkston, Nina Persson & The Second Hand Orchestra -> James
Yorkston
Fixes an issue where each spotify query was converted to ascii before sending. Adds a
new config option to enable legacy behaviour.
A file called japanese_track_request.json was made to mimic the Spotify
API response since I don't have the credentials. Entries in that will
need to be modified with the actual entries.
Co-authored-by: Sebastian Mohr <sebastian@mohrenclan.de>
Co-authored-by: Sebastian Mohr <39738318+semohr@users.noreply.github.com>
Co-authored-by: J0J0 Todos <2733783+JOJ0@users.noreply.github.com>
Adds replace plugin. The plugin allows the user to replace the audio
file of a song, while keeping the tags and file name.
Some music servers keep track of favourite songs via paths and tags. Now
there won't be a need to 'refavourite'. Plus, this skips the
import/merge steps.
Add link to community plugin
[`beets-filetote`](https://github.com/gtronset/beets-filetote).
This plugin is the spiritual successor to
[beets-copyartifacts](https://github.com/adammillerio/beets-copyartifacts)
(`beets-copyartifacts3` was last updated 3 years ago) and
[beets-extrafiles](https://github.com/Holzhaus/beets-extrafiles) (last
updated 5 years ago).
Given the updates and changes in beets and how outdated those plugins
are, does it make sense to keep `beets-copyartifacts` in the community
plugins list?
---------
Co-authored-by: Sebastian Mohr <39738318+semohr@users.noreply.github.com>
Fix ocurrence of `UnboundLocalError` in plugins/listenbrainz >
`get_tracks_from_listens()` when `mbid` is not available.
Removed a print statment.
Fix link to config.yaml.
Fix link to Listenbrainz "get the token" documentation.
Co-authored-by: Šarūnas Nejus <snejus@protonmail.com>
URL-encode additional item `fields` within generated EXTM3U playlists instead of JSON-encoding them.
This is because JSON-encoding additional fields/attributes made it difficult to parse the `EXTINF` line but using URL-encoding for these values makes parsing easy (because URL-encoded values cannot contain commas, quotation marks and spaces).
I introduced the generation of additional EXTM3U item fields earlier this year and I want to correct that now.
**Design/definition background:**
Unfortunately, I didn't find a clear definition of how additional playlist item attributes should be encoded - apparently there is none.
Given that item URIs within an M3U playlist can be URL-encoded already, defining the values of additional attributes to be URL-encoded is consistent design.
I didn't find examples of additional EXTM3U item attributes in the web where the attribute value contains a comma, space or quotation mark but examples that specified numeric IDs and URLs as attribute values.
Because the URL attribute examples I found didn't contain URL-encoded characters and because it is more readable and unproblematic for parsing, I've let the attribute URL encoding treat `:` and `/` as safe characters.
**Breaking change:**
While this is a breaking change in theory, in practice it is not since afaik all integrations of the smartplaylist plugin's additional EXTM3U item attribute generation feature (beets-webm3u) work with simple attribute values such as the item ID (numeric) whose formatting/encoding is not affected when changing from JSON to URL-encoding.
In other words the change is backward-compatible with the beets-webm3u plugin (which I'll adjust correspondingly after this beets PR was merged).
This commit introduces a distance threshold mechanism for the Genius and
Google backends.
- Create a new `SearchBackend` base class with a method `check_match`
that performs checking.
- Start using undocumented `dist_thresh` configuration option for good,
and mention it in the docs. This controls the maximum allowable
distance for matching artist and title names.
These changes aim to improve the accuracy of lyrics matching, especially
when there are slight variations in artist or title names, see #4791.
Keep both options' "Configuration" chapter texts as compact as possible,
while linking to a new chapter that describes all 4 possible
combinations in detail.
I've spent 2 hours troubleshooting why none of my music had genre tag.
It was because the single `genre`, without `s` doesn't seem to cover any
good ganre tags... at least it didn't on my opus files
looking at the code:
7ecd86101e/mediafile.py (L1669-L2167)
i don't honestly know why anyone created the single `ganre` field in the
first place
When unix tools make use of an external editor, they typically check the
environment variable VISUAL and fall back to EDITOR. This commit adds the
additional check for VISUAL to the existing EDITOR check (where VISUAL is
preferred over EDITOR).
Allow generating extm3u playlists so that they contain additional item fields such as the `id`.
The feature is required by the mgoltzsche/beets-webm3u plugin (M3U server) to transform playlists using a request based item URI template which may require additional fields such as the `id`, e.g. `beets:library:track;$id`.
Beets web API already allows remote players to access audio files but it doesn't provide a way to expose the playlists defined using the smartplaylist plugin.
Now the smartplaylist plugin provides an option to generate ID-based item URIs/URLs instead of paths.
Once playlists are generated this way, they can be served using a regular HTTP server such as nginx.
To provide sufficient flexibility for various ways of integrating beets remotely (e.g. beets API, beets API with context path, AURA API, mopidy resource URI, etc), the new option has been defined as a template with an `$id` placeholder (assuming each remote integration requires a different path schema but they all rely on using the beets item `id` as identifier/path segment).
To prevent local path-related plugin configuration from leaking into a HTTP URL-based playlist generation (invoked with CLI option in addition to the local playlists generated into another directory), setting the new option makes the plugin ignore the other path-related options `prefix`, `relative_to`, `forward_slash` and `urlencode`.
Usage examples:
* `beet splupdate --uri-format 'http://beets:8337/item/$id/file'` (for beets web API)
* `beet splupdate --uri-format 'http://beets:8337/aura/tracks/$id/audio'` (for AURA API)
(While it was already possible to generate playlists containing HTTP URLs previously using the `prefix` option, it did not allow to generate ID-based URLs pointing to the beets web API but required to expose the audio files using a web server directly and refer to them using their file system `$path`.)
Relates to #5037
The boolean flags `--extm3u` and `--no-extm3u` are replaced with a string option `--output=m3u|m3u8`.
This reduces the amount of options and allows to evolve the CLI to support more playlist output formats in the future (e.g. JSON) without polluting the CLI at that point.
