# Generalize some of common tagging functionality to `Info` and `Match`
base classes
This PR centralises some common tagging functionality between singletons
and albums allowing to simplify `ChangeRepresentation` and importing
functionality. This is prep work for a larger PR which refactors and
simplifies the entire tagging workflow.
## Changes
- **Core type changes**: Changed `mapping` parameter from `Mapping[Item,
TrackInfo]` to `list[tuple[Item, TrackInfo]]` in `apply_metadata()`,
`distance()`, and `assign_items()` functions
- **Match dataclasses**: Converted `AlbumMatch` and `TrackMatch` from
`NamedTuple` to `@dataclass`, introducing base `Match` class with common
functionality
- **New properties**: Added `name` cached property to `Info` class for
unified name access
- **ChangeRepresentation refactor**: Converted to `@dataclass` with lazy
property evaluation, replacing `cur_album`/`cur_title` with unified
`cur_name` field
- **UI improvements**: Simplified display logic by using
`match.info.name` instead of type-specific field checks
- **Parameter renaming**: Renamed `search_album`/`search_title`
parameters to `search_name` for consistency across singleton and album
workflows
The changes maintain backward compatibility in behavior while improving
type safety and code clarity.
In the fetch_text method (line ~207):
if not r.encoding:
r.encoding = "utf-8" # ← Double quotes!
In the scrape method, make sure there are 2 blank lines before the next class:
return None
class Tekstowo(SearchBackend): # ← Two blank lines above
That should pass the formatting check! The repo follows PEP 8 style (double quotes, 2 blank lines between classes).
## Key Improvements (addressing reviewer feedback):
- ✅ Uses regex instead of while loop (more efficient, one pass)
- ✅ No infinite loop risk
- ✅ Handles any number of backslashes before quotes
- ✅ Clear inline comments
## Problem
The lyrics plugin has two bugs that corrupt fetched lyrics:
1. **Unicode corruption**: Characters like `ò`, `è`, `à` are corrupted to `√≤`, `√®`, etc.
2. **Escaped quotes**: Quotes appear as `\"` instead of `"` in lyrics
## Root Causes
### Issue 1: MacRoman encoding misdetection
- **Location**: `RequestHandler.fetch_text()` line 220
- **Cause**: Setting `r.encoding = None` forces requests to use `apparent_encoding`
- **Problem**: For Genius.com (and others), requests incorrectly detects MacRoman instead of UTF-8
- **Result**: UTF-8 bytes `c3 b2` (ò) decoded as MacRoman produces "√≤" (U+221A U+2264)
### Issue 2: Incomplete JSON unescape
- **Location**: `Genius.scrape()` line 576
- **Cause**: The `remove_backslash` regex doesn't handle all escape patterns in JSON
- **Problem**: Genius embeds lyrics in JSON with patterns like `\\"` and `\\\\"`
- **Result**: After BeautifulSoup processing, escaped quotes remain in final text
## Solution
### Fix 1: Trust server encoding, fallback to UTF-8
```python
# OLD: r.encoding = None
# NEW:
if not r.encoding:
r.encoding = 'utf-8'
```
- Respects server's declared encoding (UTF-8 for Genius)
- Falls back to UTF-8 if no encoding specified (safer than apparent_encoding)
- Preserves original intent of handling misconfigured servers
### Fix 2: Iteratively clean escaped quotes
```python
while '\\"' in lyrics:
lyrics = lyrics.replace('\\"', '"')
```
- Handles variable escape levels (`\"`, `\\\"`, `\\\\\"`)
- Minimal change - keeps original `remove_backslash` regex
- Applied after BeautifulSoup to avoid interfering with HTML parsing
## Testing
Tested with:
- Caparezza - "Argenti Vive" (Italian, many accented characters)
- WestsideGunn - "Heel Cena" (escaped quotes in lyrics)
Before:
```
mi si parò davanti
\\"I got big moves\\"
```
After:
```
mi si parò davanti
"I got big moves"
```
## Impact
- Fixes lyrics for all languages with non-ASCII characters
- Fixes Genius lyrics with quotes
- No breaking changes - maintains backward compatibility
- Minimal code changes (14 lines total)
fixes#6104
## Description
When using the `fromfilename` and `edit` plugins together during import,
aborted edit sessions could silently discard the temporary tags injected
by `fromfilename` (e.g., track number and title derived from the
filename). This happened when using `eDit` or `edit Candidates` and then
cancelling: the edit plugin reverted objects by re-reading from disk,
which does not contain the `fromfilename`-generated metadata.
This PR changes the `edit` plugin so that cancel and “continue Editing”
both roll back objects to the original in-memory snapshot captured
before opening the editor, instead of reloading from the files. This
preserves temporary tags provided by other plugins (like `fromfilename`)
across aborted edit sessions, while still only writing to disk when the
user chooses Apply.
`importer_edit` is also updated to rely on this rollback behavior when
edits are cancelled, rather than re-reading from disk, so interactive
imports resume with the same in-memory metadata they started with.
Prevents a crash when "skip" is selected in the importer and
`task.imported_items()` runs into a condition branch that supposedly
should never be reached:
```
File "beets/beets/importer/tasks.py", line 254, in imported_items
assert False
^^^^^
AssertionError
```
- Since for items/albums that should be skipped, looping through
`task.imported_items()` is not required anyway, the fix here is to exit
early from the function that calls it.
- Additionally this PR fixes the original changelog entry which was
located at an older releases "new features list". Also now it briefly
explains to changelog readers what the plugin actually does.
- Two new tests were added that proof that "skip doesn't crash" and
reimports never "suggest removal of source files"
---------
Co-authored-by: Doron Behar <doron.behar@gmail.com>
This PR refactors the MusicBrainz plugin implementation by replacing the
`musicbrainzngs` library with direct HTTP API calls using `requests` and
`requests-ratelimiter`.
**Key Changes:**
- **New utilities module**: Added `beetsplug/_utils/requests.py` with
`TimeoutSession` class and HTTP error handling (`HTTPNotFoundError`,
`CaptchaError`)
- **MusicBrainz API rewrite**: Replaced `musicbrainzngs` dependency with
custom `MusicBrainzAPI` class using direct HTTP requests
- **Rate limiting**: Integrated `requests-ratelimiter` for API rate
limiting instead of `musicbrainzngs.set_rate_limit()`
- **Data structure updates**: Updated field names to match MusicBrainz
JSON API v2 format (e.g., `medium-list` → `media`, `track-list` →
`tracks`)
- **Dependency management**:
- Made `musicbrainzngs` optional and added it to plugin-specific extras
(`listenbrainz`, `mbcollection`, `missing`, `parentwork`). Updated
plugin docs accordingly.
- Made `requests` a required dependency to ensure backwards
compatibility (ideally, we would make it an optional dependency under
`musicbrainz` extra).
- **Error handling**: Simplified error handling by removing
`MusicBrainzAPIError` wrapper class
**Benefits:**
- Direct control over HTTP requests
- Consistent rate limiting across all network requests
- Better alignment with modern MusicBrainz API responses
The changes maintain backward compatibility while modernizing the
underlying implementation.
Fixes#5553Fixes#5095
See this line in https://musicbrainz.org/doc/MusicBrainz_API#Lookups
> To include more than one subquery in a single request, separate the arguments to inc= with a + (plus sign), like inc=recordings+labels.
Introduce a new RequestHandler base class to introduce a shared session,
centralize HTTP request management and error handling across plugins.
Key changes:
- Add RequestHandler base class with a shared/cached session
- Convert TimeoutSession to use SingletonMeta for proper resource
management
- Create LyricsRequestHandler subclass with lyrics-specific error
handling
- Update MusicBrainzAPI to inherit from RequestHandler
- Add preserving strings that are all lowercase or all upper case
- Fix spelling of 'separator' in config, docs and code
- Move most of the logging for the plugin to debug to keep log cleaner.
Improvements I found a need for in my daily use with the plugin.
- [x] Documentation. (If you've added a new command-line flag, for
example, find the appropriate page under `docs/` to describe it.)
- [x] Changelog. (Skipping as the plugin has not been released yet)
- [x] Tests. (Very much encouraged but not strictly required.)
## Description
Fixes#6183
The problem was that the plugin was combining multiple queries using
`OrQuery`, which didn't preserve the order in which queries were
specified in the configuration.