Background
Surfaced during investigation of #180. On the admin release detail page for bd2e3cc9-1191-47ff-b5b3-ec0a236ce34d ("Recuerdos" by Los Panchos), the header reads:
Tracks: 4 tracks
But the new Apple Music tracklist presence-check gate, which queries recording_releases for the same release id, found only 1 row:
✗ Tracklist gate rejected [local]: presence check: only 0/1 of our known
local tracks appear on Apple's album — at least one of the tracks we
have for this release is missing
So two different "tracklist size" views of the same release disagree: the admin header says 4, the gate's recording_releases ⨝ recordings view says 1.
What to investigate
- Which query / source backs the "Tracks: N tracks" display in
browse_release_detail.html? Best guess: it pulls from a recordings × recording_releases join, or from a cached MusicBrainz count on the release row, or counts MB tracks via get_release_tracklist. Find it.
- What does
SELECT count(*) FROM recording_releases WHERE release_id = 'bd2e3cc9-…' actually return? If it's truly 1, why is the header reporting 4?
- Are the two numbers measuring the same thing, or different things?
- Plausible "same thing, one is wrong": the header is reading from a stale cache, or counting something it shouldn't.
- Plausible "different things": the header counts every recording the release contributes to (across songs we've imported), while
recording_releases only has rows for recordings we've actually linked at the track-position level — a real partial-data story.
Why it matters
Not blocking — the gate uses recording_releases correctly as "tracks we've linked at a specific position on this release," and that's the right shape for a presence check. But the operator-facing display being inconsistent makes diagnoses confusing, and if the header IS right, the gate might be working from a smaller surface than it should.
Acceptance
- Documented (in a comment here, or a CLAUDE.md note) what each view counts and why they can differ.
- If one is wrong, fixed.
- If they're measuring different things on purpose, the admin header should probably surface both numbers ("4 tracks on this release; 1 with positions linked").
Background
Surfaced during investigation of #180. On the admin release detail page for
bd2e3cc9-1191-47ff-b5b3-ec0a236ce34d("Recuerdos" by Los Panchos), the header reads:But the new Apple Music tracklist presence-check gate, which queries
recording_releasesfor the same release id, found only 1 row:So two different "tracklist size" views of the same release disagree: the admin header says 4, the gate's
recording_releases ⨝ recordingsview says 1.What to investigate
browse_release_detail.html? Best guess: it pulls from arecordings×recording_releasesjoin, or from a cached MusicBrainz count on the release row, or counts MB tracks viaget_release_tracklist. Find it.SELECT count(*) FROM recording_releases WHERE release_id = 'bd2e3cc9-…'actually return? If it's truly 1, why is the header reporting 4?recording_releasesonly has rows for recordings we've actually linked at the track-position level — a real partial-data story.Why it matters
Not blocking — the gate uses
recording_releasescorrectly as "tracks we've linked at a specific position on this release," and that's the right shape for a presence check. But the operator-facing display being inconsistent makes diagnoses confusing, and if the header IS right, the gate might be working from a smaller surface than it should.Acceptance