## 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
