[pull] master from beetbox:master #189
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
2025 won't be in the future, forever. Fixes: https://bugs.debian.org/1091495
I had previously tested the `munkres` -> `lapjv` replacement extensively, so I was today surprised to find that nothing gets matched correctly when I tried importing some new tracks. On the other hand I now remember making a small adjustment in the logic to make autotagging tests pass which is when I introduced a bug: I did not realize that `lapjv` returns index '-1' for each unmatched item. This issue did not get caught by tests because this 'unmatched' item index '-1' anecdotally ended up pointing to the last (expected) item in the test making it pass. This commit adjusts the aforementioned test to catch this issue and fixes the logic to correctly identify unmatched tracks.
These tests depend on certain `track_length_grace` and `track_length_max` configuration which was set by other tests in this module. I discovered this issue when I tried to run `test_order_works_when_track_names_are_entirely_wrong` test only - I found that my local configuration was read and the test failed.
## Description Fixes #5512. When sorting on a field, if the field is missing from some items and it has a type, use the type's `null` value. Otherwise, continue to fall back to an empty string, as I don't think there's much to be done in that case. The new test `test_int_field_present_in_some_items` fails without the fix in `query.py`.
## Problem A regression was introduced when adjusting the track matching logic to use `lapjv` instead of `munkres`. The `lapjv` algorithm returns `-1` for unmatched items, which wasn't being handled correctly in the matching logic. This caused incorrect track assignments when importing new music. ## Solution - Modified the mapping creation to filter out unmatched items (where index is `-1`) - Updated test case to properly catch this scenario
# Improve release notes formatting / changelog conversion from rst to md During our last release, we discovered issues with changelog formatting. This PR improves and fixes several aspects: ## Changes - Rewrite the changelog conversion logic to be more robust and maintainable - Fix indentation issues with nested bullet points - Improve handling of long section headers - Order bullet points alphabetically within sections for better readability - Use Sphinx `objects.inv` to resolve references and include links to the documentation in _Markdown_ - Add tests to prevent formatting regressions - Add pandoc as a dependency for Ubuntu CI builds - Ensure documentation is built before generating changelog
When `lastgenre.source: track` is configured, - `lastgenre -a` _should not_ fall back to the album level genre (by making use of the with_album=False kwarg of the Libary's get method). - `lastgenre -a`, when finally storing the genres of _an album_, should _not_ also write the tracks genres (by making use of the inherit=False kwarg of the Album's store method.
It was rather confusing that the lastgenre plugin, when handling singletons, sometimes showed that it applied genres from last.fm and sometimes didn't (it did only in debug log). This streamlines the behaviour: - Change debug to info log. - Streamline wording. - Display details about the track.
is configured.
- Printing out album/item in default format could lead to unreadable clutter depending on the user's configured formats. - The album's name and the individual tracks' title should be just sufficient to provide context as well readability. - Log like this while importing as well as in standalone runs.
- Fix `lastgenre -A` in combination with config option `source: track` (_Tracks inherited the album's genre even when this option was set_) - Now, When an album-level genre is set already, single tracks don't fall back to the album's genre and request their own last.fm genre. - Fix log-level and message wording being slightly different for `source:` track, album, artist genre - Now log messages follow the same wording, level and structure throughout.
Ubuntu version in GitHub Actions has recently been upgraded to 24.04: actions/runner-images#10636) This meant that pandoc was upgraded and it changed the way markdown is formatted by default.
Revert normpath additions
- genres are now called tags - tags needs to be in "mb fetch includes" - release-group has them - release has them - and recording as well but we don't use them - not sure what this outdated check was doing, it looked at "recordings" in the valid list even though genre fetching is only included in the `album_info` code and not `track_info` 🤷 - see musicbrainz.VALID_INCLUDES for reference
## Description 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; see [here](https://github.com/mgoltzsche/beets-webm3u/blob/v0.6.4/beetsplug/webm3u/playlist.py#L102) and [here](https://github.com/mgoltzsche/beets-webm3u/blob/v0.6.4/beetsplug/webm3u/playlist.py#L122)). [I introduced the generation of additional EXTM3U item fields earlier this year](#5121) and I want to correct that now.
## Description Hello y'all. One of the dev from the [beets-flask app](https://github.com/pSpitzner/beets-flask) here. We are extending the `ImportSession` in our application to get the interactive imports working in our application. Overall that was not a too pleasant experience as a ton of typehints are missing in that area of the beets code. This PR wants to fix this ;) ### Changes Moved importer state logic into a dataclass. Is clearer and more isolated now in my opinion, we are not using it but I found it quite confusing when looking at it. Added a ton of typehints to the `importer.py` file. Predominantly the `ImportSession`, `ImportTask` (and derivatives) and pipeline stage decorators are now (hopefully) completely typed. Additionally I fixed some typhint issues in the `util.__init__.py` file, mainly related to the `PathLike` type. If you have some strong opinions about any of the changes feel free to revert or edit the PR. Best, Sebastian P.S: I noticed that beets does not use Abstract Base Classes is there any reason for that or is it just of historic nature? I think some Base Classes could be adapted to use an ABC metaclass quite easily.
I found that the translator would sometimes replace the pipe character with another symbol (maybe it got confused thinking the character is part of the text?). Added spaces around the pipe to make it more clear that it's definitely the separator.
…dling (#5485) 🎵 The Refactoring Blues 🎵 by [Claude](https://claude.ai) Verse 1: Got those lyrics plugin blues Cleaning up some messy code Moving classes, fixing views Making changes down the road Chorus: We're refactoring tonight Making the codebase clean and bright Translation's got a brand new home And ReST files found their own Verse 2: Added Microsoft Translate Keeping tokens safe and sound Config options up-to-date Better structure all around Bridge: Path operations simplified Groups of artists, neat and tied Error handling's looking fine Comments clear along each line Verse 3: RestFiles in their own class now Cleaning imports, showing how Better typing makes it clear What should go and what stays here Final Chorus: We're refactoring tonight Making the codebase clean and bright Translation's got a brand new home And our code can stand alone! — inspired by _the diff_ --- ### Technical Changes - Replaced deprecated and broken Bing translations by Microsoft Translator API - Isolated all functionality in the `Translator` class. - Updated translation settings configuration. - Added support for synced lyrics from LRCLib. - Added support for preserving existing translations to help users to manage their characters quota. - Added error handling and logging - Added tests - Created RestFiles class for ReST document handling - Simplified path operations using pathlib - Added tests - Improved command line options handling #### Caching of translations The plugin will not re-translate lyrics if translations already exist, see ```fish $ beet -v lyrics albumartist::Sel karta -f ... lyrics: LyricsPlugin: Fetching lyrics for Sel - Saulės Miestas lyrics: LRCLib: Fetching JSON from https://lrclib.net/api/get lyrics: LyricsPlugin: 🟢 Found lyrics: 32275 | 1996 / Neįvertinta Karta: Sel - Saulės Miestas lyrics: Translator: Posting data to https://api.cognitive.microsofttranslator.com/translate lyrics: Translator: 🟢 Translated lyrics to EN $ beet -v lyrics albumartist::Sel karta -f ... lyrics: LyricsPlugin: Fetching lyrics for Sel - Saulės Miestas lyrics: LRCLib: Fetching JSON from https://lrclib.net/api/get lyrics: LyricsPlugin: 🟢 Found lyrics: 32275 | 1996 / Neįvertinta Karta: Sel - Saulės Miestas lyrics: Translator: 🔵 Translations already exist ```
## Description My library is managed using Beets for organization and [git-annex](https://git-annex.branchable.com/) as storage backend. Therefore when using this system, while my library files always exists on my filesystem, some files may be empty (without content). In this case, when I'm running the `convert` plugin, I don't wants it to process files which are empty (same apply for any Beets plugin). Hence, I added a check that the file is readable as a `MediaFile` before doing any process. Before this fix, trying to encode an empty file would have lead to an error while leaving `convert` doing its side-effects **and** `convert` would also copy empty files to destination for files that doesn't need to be re-encoded. In my case, this is empty files, but the problem can be anything else (depending on the storage backend) and/or corrupted files. Conclusion, I think **checking that the file is readable is always recommended before proceeding to heavy operation** like this.
…' is not defined (#5651) 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>
Add link to community plugin beets-id3extract
Bump python version in the CI to current versions. This is the same as #5503 that for some reason got closed when the merge of the `drop-py38` branch happened
Fixes #5669 SCREENSHOT ATTACHED- 
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )