Adds a zero_disc_number_if_single_disc boolean to the zero plugin for writing to files. Adds the logic that, if disctotal is set and there is only one disc in disctotal, that the disc is not set.
This keeps tags cleaner, only using disc on multi-disc albums. The disctotal is not touched, particularly as this is not usually displayed in most clients.
The field is removed only for writing the tags, but the disc number is maintained in the database to avoid breaking anything that may depend on a disc number or avoid possible loops or failed logic.
## Description
- removes all mailing list references in doc.
- removes outdated installation instructions (python3.8 + slackware)
- modernizes the getting started guide
closes#5462
This PR refactors the metadata source plugin architecture to fix
incorrect data source penalty calculations during import matching.
**Key Changes:**
- **Fixed distance calculation**: Removed `track_distance()` and
`album_distance()` methods from `MetadataSourcePlugin`. Data source
mismatch penalty is now calculated directly in
`beets/autotag/distance.py`, same as most of the rest of field-based
penalties.
- **Plugin registration**: Metadata source plugins now register
themselves in `_instance_by_data_source` dict on instantiation, enabling
efficient penalty lookups.
- **Renamed configuration options**:
- `source_weight` → `data_source_mismatch_penalty` (plugin-level)
- `match.distance_weights.source` → `match.distance_weights.data_source`
(global matching)
- **Documentation**: added a `yaml` block with default configuration
values to each metadata source documentation page. Included the renamed
penalty field in each to underline that it's available for each data
source.
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.
### b5216a0 is a proposed fix for #5218
We don't assume anymore that if the pattern lacks the "artist" group it
also has the "title" group (this was causing the "title" KeyError, when
the pattern containg only the `?P<track>` group is used).
Instead, we check for existence of "title" before assigning
"title_field", otherwise we let the last pattern (which will always
match) to assign it. The only slight drawback is that files like
"01.mp3" will also get "01" as title (besides the "1" track number),
instead of having no title, but I guess that is not going to cause any
major problem in the rest of the import procedure (e.g. track matching
after a search). On the other hand, I guess allowing a file to have no
title would require a substantial rewriting of the plugin, since the
empty string is in BAD_TITLE_PATTERNS.
### 0966042 adds a log message about the pattern being tried
This is useful while debugging changes to the regexps in PATTERNS.
I used loglevel "debug" for this message, should we use "debug" also for
other messages (currently using level "info")?
### e6b7735 refactors the regexps in PATTERNS
I reviewed the regexps (especially after the changes I made some time
ago in 84cf336) and tried to make them cleaner.
- Allow " - " and "-" as separator between track/artist/title fields:
that should cover two common filename conventions: using spaces (e.g.
`01 - Artist Name - Title of the song`) or not using spaces (e.g.
`01-artist_name-title_of_the_song`). Some regexp groups are non-greedy,
to avoid capturing unwanted leading/trailing spaces in artist/titles; we
could think about some other enhancements, e.g. automatically converting
underscores to spaces in artist/title names, but I guess the main use of
the plugin is not to produce a perfectly formatted title, but a
sufficient meaningful one to be used as reference in the following
stages of the update procedure.
- Allow `?P<tag>` groups by making them optional in the first two
patterns (instead of having two versions of the pattern, with or without
tag). BTW I'm not sure what these groups are about: we optionally check
for them in the plugin, but we never use them to assign any metadata.
- Allow optional "." after the track number
- In the third pattern: also allow "_" as separator (e.g. for file names
like `01_some_tack.mp3`)
