Pin type='track' / type='artist' collision case for album-type normalizer

pull/570/head
Broque Thomas 3 days ago
parent 5eae24b8bb
commit 46206b3240

@ -130,3 +130,19 @@ class TestLegacyBuilderAlbumTypeAltKeys:
a stray value from poisoning the path template."""
info = self._build({'type': 'Mixtape'})
assert info['album_type'] == 'album'
def test_type_track_collision_defaults_to_album(self):
"""`type` is a generic key name — many dict shapes use it
for entity discrimination (Deezer track responses carry
`type='track'`, Spotify search results use it for
`artist`/`track`/`album`/etc). If a caller hands us a dict
that has `type='track'` (track data passed by mistake, or a
merged shape where `type` discriminates entity rather than
album category), the normalizer must treat it as unknown and
default to `album` not silently classify the result as some
bogus 'track' folder."""
info = self._build({'type': 'track'})
assert info['album_type'] == 'album'
info = self._build({'type': 'artist'})
assert info['album_type'] == 'album'

@ -3416,7 +3416,7 @@ const WHATS_NEW = {
'2.5.2': [
// --- post-release patch work on the 2.5.2 line — entries hidden by _getLatestWhatsNewVersion until the build version bumps ---
{ date: 'Unreleased — 2.5.2 patch work' },
{ title: '$albumtype Folder Template Now Splits EPs / Singles For Non-Spotify Sources', desc: 'discord report (cal): downloading an artist\'s discography with `$albumtype` in the path template put every release under `Album/` regardless of actual type — eps, singles, all dumped into the album folder. trace: the legacy duck-typed album-info builder at `core/metadata/album_tracks.py:_build_album_info_legacy` only checked the `album_type` key. spotify uses `album_type` (lowercase) so spotify discographies worked. but deezer\'s api uses `record_type`, tidal uses `type` (uppercase ALBUM/EP/SINGLE), and some flattened musicbrainz shapes use `primary-type` — none of those matched, all defaulted to `album`. fix: widen the legacy lookup to check `album_type` / `record_type` / `type` / `primary-type` and route the value through a new pure `_normalize_album_type` helper that lowercases + validates against the canonical token set (`album` / `single` / `ep` / `compilation`) and falls back to `album` for unknowns. typed-converter path for spotify / deezer / itunes / discogs / musicbrainz / hydrabase / qobuz unchanged — they were already correct. tidal users were the main offender (no typed converter for dict-shaped tidal data). 24 new tests pin: case-insensitive normalization for each canonical type, compilation preserved (spotify supports it), unknown values default to album, defensive against none / empty / non-string inputs, multi-key precedence (`album_type` wins over `record_type`), each known source shape produces correct token.', page: 'tools' },
{ title: '$albumtype Folder Template Now Splits EPs / Singles For Non-Spotify Sources', desc: 'discord report (cal): downloading an artist\'s discography with `$albumtype` in the path template put every release under `Album/` regardless of actual type — eps, singles, all dumped into the album folder. trace: the legacy duck-typed album-info builder at `core/metadata/album_tracks.py:_build_album_info_legacy` only checked the `album_type` key. spotify uses `album_type` (lowercase) so spotify discographies worked. but deezer\'s api uses `record_type`, tidal uses `type` (uppercase ALBUM/EP/SINGLE), and some flattened musicbrainz shapes use `primary-type` — none of those matched, all defaulted to `album`. fix: widen the legacy lookup to check `album_type` / `record_type` / `type` / `primary-type` and route the value through a new pure `_normalize_album_type` helper that lowercases + validates against the canonical token set (`album` / `single` / `ep` / `compilation`) and falls back to `album` for unknowns. typed-converter path for spotify / deezer / itunes / discogs / musicbrainz / hydrabase / qobuz unchanged — they were already correct. tidal users were the main offender (no typed converter for dict-shaped tidal data). 25 new tests pin: case-insensitive normalization for each canonical type, compilation preserved (spotify supports it), unknown values default to album, defensive against none / empty / non-string inputs, multi-key precedence (`album_type` wins over `record_type`), each known source shape produces correct token, generic `type='track'` / `type='artist'` collision case defaults to album rather than poisoning the path.', page: 'tools' },
],
'2.5.1': [
// --- May 12, 2026 — 2.5.1 release ---

Loading…
Cancel
Save