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.
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.
# 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
## 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
## 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`.
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.
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.
I found out that GitHub Actions use pandoc version 2.9.2.1 which
converts bullet points like this:
echo '
* Item
* Another item
' | pandoc --from=rst --to=gfm
- Item
- Another item
Note that each item has two-space indent. Meanwhile, locally I've been
testing this conversion using pandoc 3.5 which does not add any indent:
echo '
* Item
* Another item
' | pandoc --from=rst --to=gfm
- Item
- Another item
This commit removes the indent and cleans up the how the replacements in
rst and md text are performed.
Fixes#5207.
This PR replaces the `munkres` library with `lap` (Linear Assignment
Problem solver) for computing optimal track assignments during the
auto-tagging process. The main changes are:
- Remove `munkres` dependency and add `lap` and `numpy` dependencies
- Refactor the track assignment code to use `lap.lapjv()` instead of
`Munkres().compute()`
- Simplify cost matrix construction using list comprehension
- Move config value reading outside of `track_distance` function to
improve performance
The motivation for this change comes from benchmark comparisons showing
that LAPJV (implemented in the `lap` library) significantly outperforms
the Munkres/Hungarian algorithm for the linear assignment problem. See
detailed benchmarks at: https://github.com/berhane/LAP-solvers
The change should provide better performance for track matching,
especially with larger albums, while maintaining the same assignment
results.
## Testing Notes
- All existing tests pass without modification
- Track assignments produce identical results
- No behavioral changes in auto-tagging
Fixes#4622.
I don't think this changes other behavior of the function, but it fixes
the problem with the moved files being created with the wrong
permissions for me.
Thanks to @wisp3rwind's suggestion this PR adds types to the
relationship between `Model`, `Database` and `Library`.
Then I worked through the rest of the issues found in the edited files.
Most of this involved providing type parameters for generic types (or
defining defaults, rather 😉).
There `queryparse` module had a somewhat significant issue where the
sorting construction logic only expected to receive `FieldSort`
subclasses, while `SmartArtistSort` was not one. Thus `SmartArtistSort`
has now been forced to behave and is a `FieldSort` subclass. It's also
been moved to `query.py` module which is where the rest of sorts are
defined.
This PR fixes an issue where the `beet write` command repeatedly shows
differences for certain fields (`mb_artistid`, `mb_albumartistid`,
`albumtype`) even after writing the tags.
This happens because these fields are actually stored as lists in the
media files (`mb_artistids`, `mb_albumartistids`, `albumtypes`), but
beets maintains both single and list versions in its database.
This PR addresses this issue in a non-invasive way: the fix ensures
consistency between single fields and their list counterparts by:
1. When setting a single field value, making it the first element of the
corresponding list
2. When setting a list, using its first element as the single field
value
This resolves long-standing issues #5265, #5371, and #4715 where users
experienced persistent "differences" in these fields despite writing
tags multiple times.
Changes:
- Added `ensure_consistent_list_fields()` function to synchronize field
pairs
- Applied this function during metadata application
- Added tests for all field combinations
Fixes#5265, #5371, #4715
**Note**: your music needs to be reimported with `beet import -LI` or
synchronised with `beet mbsync` in order to fix these fields!
