fix: look tags up by artist name rather than by MusicBrainz id #11

2026-08-24T18:14:04+01:00

lyrathorpe commented

2026-08-24 18:14:04 +01:00

Problem

WARNING no tags for DEVO: error 6: The artist you supplied could not be found
WARNING no tags for Escape the Fate: error 6: ...
WARNING no tags for Frank Carter & the Rattlesnakes: error 6: ...

Those artists exist on Last.fm. Verified against the live pages:

last.fm/music/Devo — 1.4M listeners, tagged new wave, post-punk, 80s
last.fm/music/Escape+the+Fate — 1.5M listeners, tagged post-hardcore,
screamo, emocore

Exactly the tags the moods are built from, and both were skipped.

The cause is which key the lookup used. sync_tags asked by MusicBrainz id
whenever Lidarr had one, which is always. The reasoning was that an id cannot be
ambiguous the way a name can; in practice Last.fm's mbid index is stale and
partial, while its name index is the one its own site runs on.

Second fault

A failed lookup was logged and skipped without recording the attempt, so
every one of those artists was re-queried on every subsequent pass,
indefinitely. On this library that is a few hundred wasted requests per pass,
for ever.

Change

Ask by name first. Keep the mbid only as a fallback, for a name Lidarr spells
differently to Last.fm.
Distinguish the two kinds of failure. An artist that neither key resolves
is recorded as fetched with no tags and not asked about again. A genuine
failure -- rate limit, bad key -- is deliberately left unrecorded so the next
pass retries it. Telling those apart needed the service's own error number, so
LastfmError now carries it.

Testing

98 tests, green locally and in docker build --target test. The Last.fm fake now
returns error 6 for a key it cannot resolve, as the real service does, rather
than an empty tag list -- which is why this was not caught the first time. New
tests cover name-first ordering, the mbid fallback firing only when the name
fails, an unresolvable artist not being retried, and a hard failure still being
retried.

After merging

Artists already recorded keep their (empty) results until the ninety-day
refresh. To re-run them immediately:

docker exec music-curator python -c "import sqlite3; d=sqlite3.connect('/data/curator.db'); d.execute('DELETE FROM artist_tag_fetched'); d.commit()"

## Problem WARNING no tags for DEVO: error 6: The artist you supplied could not be found WARNING no tags for Escape the Fate: error 6: ... WARNING no tags for Frank Carter & the Rattlesnakes: error 6: ... Those artists exist on Last.fm. Verified against the live pages: - `last.fm/music/Devo` — 1.4M listeners, tagged **new wave, post-punk, 80s** - `last.fm/music/Escape+the+Fate` — 1.5M listeners, tagged **post-hardcore, screamo, emocore** Exactly the tags the moods are built from, and both were skipped. The cause is which key the lookup used. `sync_tags` asked by MusicBrainz id whenever Lidarr had one, which is always. The reasoning was that an id cannot be ambiguous the way a name can; in practice Last.fm's mbid index is stale and partial, while its name index is the one its own site runs on. ## Second fault A failed lookup was logged and skipped **without recording the attempt**, so every one of those artists was re-queried on every subsequent pass, indefinitely. On this library that is a few hundred wasted requests per pass, for ever. ## Change - Ask by name first. Keep the mbid only as a fallback, for a name Lidarr spells differently to Last.fm. - Distinguish the two kinds of failure. An artist that **neither** key resolves is recorded as fetched with no tags and not asked about again. A genuine failure -- rate limit, bad key -- is deliberately left unrecorded so the next pass retries it. Telling those apart needed the service's own error number, so `LastfmError` now carries it. ## Testing 98 tests, green locally and in `docker build --target test`. The Last.fm fake now returns error 6 for a key it cannot resolve, as the real service does, rather than an empty tag list -- which is why this was not caught the first time. New tests cover name-first ordering, the mbid fallback firing only when the name fails, an unresolvable artist not being retried, and a hard failure still being retried. ## After merging Artists already recorded keep their (empty) results until the ninety-day refresh. To re-run them immediately: docker exec music-curator python -c "import sqlite3; d=sqlite3.connect('/data/curator.db'); d.execute('DELETE FROM artist_tag_fetched'); d.commit()"

lyrathorpe added 1 commit 2026-08-24 18:14:04 +01:00

fix: look tags up by artist name rather than by MusicBrainz id

Build and publish container / build (pull_request) Successful in 2m53s

Details

40dfce8a4c

Tag lookups asked by MusicBrainz id whenever Lidarr had one, which is always.
The reasoning was that an id cannot be ambiguous the way a name can. In practice
Last.fm's mbid index is stale and partial, and it answered "the artist you
supplied could not be found" for Devo, Escape the Fate, Blasterjaxx, Frank
Carter & the Rattlesnakes and a long tail of others -- artists whose Last.fm
pages plainly exist and carry precisely the tags the moods are built from. Devo
is tagged new wave, post-punk and 80s; Escape the Fate is tagged post-hardcore,
screamo and emocore. Both were skipped.

Ask by name first, which is the index Last.fm's own site runs on, and keep the
id only as a fallback for a name Lidarr spells differently.

Failures were also being dropped without recording the attempt, so every one of
those artists was re-queried on every subsequent pass, indefinitely. They are now
distinguished: an artist that neither key resolves is recorded as fetched with
no tags and not asked about again, while a genuine failure -- a rate limit, a
bad key -- is deliberately left unrecorded so the next pass retries it. Telling
the two apart needed the service's own error number, so LastfmError now carries
it.

lyrathorpe merged commit 71c7115507 into main

2026-08-24 18:14:42 +01:00

lyrathorpe deleted branch fix/tag-lookup-by-name

2026-08-24 18:14:42 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lyrathorpe/music-curator#11