Desktop: album ownership badge says "in your library" for an album I hold 2 of 10 tracks of #16
Notifications
Due Date
No due date set.
Blocks
Reference: yonlu/yellowjacket#16
Reference in New Issue
Block a user
Report
I autotagged an album where I have 2 of 10 tracks. The album detail page shows a green tick and "Album [name] is in your library" instead of the expected "2 of 10 tracks ... are in your library". Inconsistency here is confusing — this needs to be accurate, consistent and communicative everywhere.
Findings
partialbadge state is only correct when the total is known:library-status-indicatordocuments that a caller with no total must passin-libraryrather than a ring at 0%, because most of an untagged library would otherwise be marked incomplete on no evidence.audio_files.total_tracks, summed per disc byGetAlbumCompleteness, falling back toexplore_index.total_tracks.tagwriterwrites track and disc numbers but not totals — so autotagging a folder actively degrades the field this rests on. That matches the report exactly: the album became MBID-matched (green tick) while the completeness evidence stayed absent.Direction
tagwriterwriteTRACKTOTAL/DISCTOTAL(and the ID3n/Nform) when the matched release tells us.total_tracksshould never fall back to the plain tick.Related: the full-tracklist toggle issue and the "make unowned content obvious" issue.
Claiming this. Branch:
fix/16-tagwriter-totals.Approach
tagwriterwrites track and disc numbers and drops the totals, so autotagging an album erases the very evidenceGetAlbumCompletenessreads — which is the mechanism the report describes. Direction step 1:TRCK/TPOSwritten as then/Nform, which is whatdhowden/tagparses (parseXofN).TRACKTOTAL/DISCTOTAL, those exact names —dhowden/tag's Vorbis reader looks attracktotal/disctotaland at nothing else (notTOTALTRACKS, and not ann/NinsideTRACKNUMBER).dbsyncpersists the total toaudio_files.total_tracks, so the row agrees with the file without waiting for a rescan.The total is per disc, because that is what
GetAlbumCompletenesssums, so autotag derives it by counting the candidate's tracks on that track's own disc rather than usingCandidate.TrackCount.Steps 2 and 3 stay open under this: the catalog fallback (2) already landed as
completenessAnswer()inexplore-album-details, and the badge call-site audit (3) is the part that overlaps #38.PR #105 is up and CI is green on both jobs (
checkande2e, run 16966).Step 1 is done and is what closes this. Steps 2 and 3 are not lost — the catalog fallback (2) had already landed as
completenessAnswer()inexplore-album-details, and the badge call-site audit (3) is #38's umbrella, which this unblocks.One finding filed on the way: #104. The WAV case of the new round-trip test failed with every field zero, not just the totals —
dhowden/taghas no RIFF reader, so nothingtagwriterputs in a WAV'sid3chunk is visible tometadata.ExtractTags. Pre-existing and invisible;wav_test.goverifies its writes by parsing that chunk itself, which is why no test ever noticed.