metadata: 1200px CAA thumbnails, stable art change-detection key #269

Merged

mysticalsoap merged 2 commits from metadata/caa-thumb1200 into trunk

2026-09-18 17:45:55 -04:00

mysticalsoap commented

2026-09-18 17:24:26 -04:00

Owner

Problem

Navidrome 0.64.0 (#223) caps decodable artwork at MaxImageSize (20 MB). album_art_sync.py pulled the Cover Art Archive's full-size originals (/front), which are raw scans: three covers here were 28-36 MB and Navidrome now logs image exceeds size cap and shows no art for them; several more sat at 9-14 MB.

Separately, the script's "unchanged source" check compared the final redirect URL, and archive.org serves each request from a different mirror host and shard prefix. Two lookups of the same image never compared equal, so every archive-sourced album would re-download at each 14-day recheck. State already held dozens of distinct mirror hosts.

Fix

Fetch /front-1200 (the archive's own 1200px thumbnail, a few hundred KB) instead of /front.
Key change detection on the archive item path (mbid-.../..._thumb1200.jpg), which is stable across mirrors.
Maintenance.md: the sentence describing state as a content hash with drift detection was wrong (the script docstring says the opposite); now describes the item-path key.

Verification

HEAD on release-group/<mbid>/front-1200 for the White Album redirects to ..._thumb1200.jpg (9 KB vs 33 KB original); three consecutive requests landed on two different mirror hosts, confirming the churn.
Forced a recheck of all 75 matched albums (last_checked reset inside the container) and ran the sync: stats={'updated': 75, 'no_source': 1}. The one no_source (LONG SEASON) 404s on /front too, pre-existing.
No cover.* under /music is over 2 MB any more (previously 11 over 5 MB, 3 over 20 MB).
Navidrome's watcher rescanned on its own; getCoverArt for the three formerly-rejected albums (Imaginal Disk, Hellfire, When the Wind Forgets Your Name) returns 200 image/jpeg.
State entries now carry mbid-<item>/<file>_thumb1200.jpg keys; a subsequent dry run queues 0 rechecks.

## Problem Navidrome 0.64.0 (#223) caps decodable artwork at `MaxImageSize` (20 MB). `album_art_sync.py` pulled the Cover Art Archive's full-size originals (`/front`), which are raw scans: three covers here were 28-36 MB and Navidrome now logs `image exceeds size cap` and shows no art for them; several more sat at 9-14 MB. Separately, the script's "unchanged source" check compared the final redirect URL, and archive.org serves each request from a different mirror host and shard prefix. Two lookups of the same image never compared equal, so every archive-sourced album would re-download at each 14-day recheck. State already held dozens of distinct mirror hosts. ## Fix - Fetch `/front-1200` (the archive's own 1200px thumbnail, a few hundred KB) instead of `/front`. - Key change detection on the archive item path (`mbid-.../..._thumb1200.jpg`), which is stable across mirrors. - Maintenance.md: the sentence describing state as a content hash with drift detection was wrong (the script docstring says the opposite); now describes the item-path key. ## Verification - HEAD on `release-group/<mbid>/front-1200` for the White Album redirects to `..._thumb1200.jpg` (9 KB vs 33 KB original); three consecutive requests landed on two different mirror hosts, confirming the churn. - Forced a recheck of all 75 matched albums (`last_checked` reset inside the container) and ran the sync: `stats={'updated': 75, 'no_source': 1}`. The one `no_source` (LONG SEASON) 404s on `/front` too, pre-existing. - No `cover.*` under `/music` is over 2 MB any more (previously 11 over 5 MB, 3 over 20 MB). - Navidrome's watcher rescanned on its own; `getCoverArt` for the three formerly-rejected albums (Imaginal Disk, Hellfire, When the Wind Forgets Your Name) returns 200 `image/jpeg`. - State entries now carry `mbid-<item>/<file>_thumb1200.jpg` keys; a subsequent dry run queues 0 rechecks.

mysticalsoap added 2 commits

2026-09-18 17:24:26 -04:00

metadata: fetch 1200px CAA thumbnails instead of full-size originals 554887f284

Navidrome 0.64 caps decodable artwork at MaxImageSize (20 MB) and logs
"image exceeds size cap" for anything larger. Three covers here were
28-36 MB scans pulled from /front; several more sat at 13 MB. /front-1200
is the archive's own 1200px thumbnail of the same image, a few hundred KB.

The resolved key changes shape for every album, so each one re-downloads
once on its next check.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

metadata: key album-art change detection on the archive item path 41205adc52

The resolved key was the final redirect target, which archive.org serves
from a different mirror host and shard prefix on every request. Two
lookups of the same image never compared equal, so every CAA-sourced
album re-downloaded at each 14-day recheck instead of the cheap HEAD-only
"unchanged" path. State already holds dozens of distinct mirror hosts.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mysticalsoap referenced this pull request

2026-09-18 17:24:39 -04:00

chore(deps): update ghcr.io/navidrome/navidrome docker tag to v0.64.0 #223

mysticalsoap merged commit 40b5e3952f into trunk

2026-09-18 17:45:55 -04:00

mysticalsoap deleted branch metadata/caa-thumb1200

2026-09-18 17:45:55 -04:00

mysticalsoap referenced this pull request from a commit

2026-09-18 17:45:56 -04:00

Merge pull request 'metadata: 1200px CAA thumbnails, stable art change-detection key' (#269) from metadata/caa-thumb1200 into trunk

mysticalsoap referenced this pull request

2026-09-18 18:04:21 -04:00