yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Autotag: strict auto-accept as a background job, and entry points from the library #90

New Issue
Open
opened 2026-08-18 20:05:29 +00:00 by yonlu · 1 comment
yonlu commented 2026-08-18 20:05:29 +00:00
Owner
Copy Link
Copy Source

The autotagger reviews one album at a time and always asks. An album whose match is unambiguous should not need a keystroke.

Phase 011 of .planning/autotag.md, which is deleted in favour of this issue and its sibling. That document is stale in its details — it predates the beets/Picard-informed scoring overhaul that shipped (recommend.go, rank.go, mixedbag.go), which already delivered the recommendation tiers, VA handling and singleton path it listed as later work. What follows is what is actually left.

The rule

An album-group qualifies for auto-accept iff: exact track-count match, every track's normalized title matches, every track's length within ±2 s, no cover-art replacement required, and no existing-MBID conflicts. The decision uses already-cached candidate data — no additional MusicBrainz calls.

recommend.go already carries the recommendation tiers this gates on and names plan 011 in its own comment; rank.go notes the cases that must refuse auto-accept entirely, and a 2-track folder cannot be auto-accept confident however well it scores. So the rule is largely a matter of wiring the existing tiers to a threshold, not inventing a new score.

The job

Auto-accept processes all qualifying groups in the queue, emits progress, and is cancellable at any point. It is a jobs registration like every other long-running operation — the same reason the discography and lyrics backfills got one: a pass that rewrites files and cannot be seen or stopped is the gap this codebase has closed three times already. It runs under WithBackgroundPriority so it cannot starve an interactive browse.

Entry points

  • Right-click on a track / album / artist exposes "Autotag this album" (queues it and jumps to review) and "Retag" (flips status to untagged and requeues).
  • After a library scan finishes with N new untagged albums, a non-blocking notification links to the autotag view. This is a Transient or Persistent notification through notification-store, not a private toast — the app has one notification surface.
  • The sidebar's pending-count badge updates reactively.

The risk, stated plainly

Release selection can pick the wrong edition. The exact-track-count gate prevents most silent misbehaviour, but bonus-track editions and remaster reissues with matching track counts are genuine ambiguity. Manual review handles the edge cases — which is why auto-accept is strict by design, and why a slider for fuzzy auto-accept is explicitly out of scope.

Every apply rewrites a file. The first-apply irreversibility warning per library is what mitigates surprise, and it must fire for the auto-accept path too, not only the manual one.

Related

#28 wants a high-confidence match surfaced on the album/artist page. That is the same confidence signal rendered somewhere else, and the two should agree on what "high confidence" means rather than computing it twice.

Done when

A run over a well-tagged subset produces zero incorrect matches, is visible in the jobs indicator, and can be cancelled mid-run without leaving a group half-applied.

The autotagger reviews one album at a time and always asks. An album whose match is unambiguous should not need a keystroke. Phase 011 of `.planning/autotag.md`, which is deleted in favour of this issue and its sibling. **That document is stale in its details** — it predates the beets/Picard-informed scoring overhaul that shipped (`recommend.go`, `rank.go`, `mixedbag.go`), which already delivered the recommendation tiers, VA handling and singleton path it listed as later work. What follows is what is actually left. ## The rule An album-group qualifies for auto-accept **iff**: exact track-count match, every track's normalized title matches, every track's length within ±2 s, no cover-art replacement required, and no existing-MBID conflicts. The decision uses already-cached candidate data — **no additional MusicBrainz calls**. `recommend.go` already carries the recommendation tiers this gates on and names plan 011 in its own comment; `rank.go` notes the cases that must refuse auto-accept entirely, and a 2-track folder cannot be auto-accept confident however well it scores. So the rule is largely a matter of wiring the existing tiers to a threshold, not inventing a new score. ## The job Auto-accept processes all qualifying groups in the queue, emits progress, and is cancellable at any point. It is a **`jobs` registration like every other long-running operation** — the same reason the discography and lyrics backfills got one: a pass that rewrites files and cannot be seen or stopped is the gap this codebase has closed three times already. It runs under `WithBackgroundPriority` so it cannot starve an interactive browse. ## Entry points - Right-click on a track / album / artist exposes "Autotag this album" (queues it and jumps to review) and "Retag" (flips status to `untagged` and requeues). - After a library scan finishes with N new untagged albums, a non-blocking notification links to the autotag view. This is a **Transient or Persistent notification through `notification-store`**, not a private toast — the app has one notification surface. - The sidebar's pending-count badge updates reactively. ## The risk, stated plainly Release selection can pick the wrong edition. The exact-track-count gate prevents most silent misbehaviour, but bonus-track editions and remaster reissues with matching track counts are genuine ambiguity. Manual review handles the edge cases — which is why auto-accept is strict by design, and why a slider for fuzzy auto-accept is explicitly **out of scope**. Every apply rewrites a file. The first-apply irreversibility warning per library is what mitigates surprise, and it must fire for the auto-accept path too, not only the manual one. ## Related #28 wants a high-confidence match surfaced on the album/artist page. That is the same confidence signal rendered somewhere else, and the two should agree on what "high confidence" means rather than computing it twice. ## Done when A run over a well-tagged subset produces **zero incorrect matches**, is visible in the jobs indicator, and can be cancelled mid-run without leaving a group half-applied.
yonlu added the Kind/Feature
Priority
Medium
3
Platform/DesktopArea/Metadata labels 2026-08-18 20:05:29 +00:00
logan commented 2026-08-19 06:37:20 +00:00
Collaborator
Copy Link
Copy Source

#28 is up as PR #121, and it lands the shared half this issue asked
for. Two things here rather than in the PR, since they are about this
issue's remaining work.

The confidence tier is now one name. autotag.ConfidentTier with
autotag.Confident(rec) beside it, in recommend.go. This issue's
"the two should agree on what high confidence means rather than
computing it twice" is what it exists for, and the comment says so.
What it deliberately does not try to be is the whole of auto-accept's
test: the extra gates named above — exact track count, every normalized
title matching, ±2 s, no cover-art replacement, no MBID conflict —
cannot be expressed as a tier, so they stay this issue's to add on top.
Reading Confident(rec) first and then applying them is the shape that
keeps the two features honest with each other.

MatchForAlbum is a worked example of the no-extra-calls rule. The
rule stated here — "uses already-cached candidate data, no additional
MusicBrainz calls" — is the same constraint the album page had, for a
different reason (its lookup fires on page open, against limiters
shared with every page the user can open). What it does:
lookupCachedCandidates(groupKey) for the durable
tagging_candidates blob, LocalTracksForGroup for the group, then
autotag.Recommend. An unscored folder answers "nothing" rather than
scoring itself. An auto-accept pass can read exactly the same way and
skip a group the prefetch has not reached, which is also the behaviour
that keeps it cancellable and restartable without losing work.

One thing #28 could not settle and this issue will have to: it declines
to act on an album that spans more than one tagging group (a
multi-disc album is one group per disc), because a single "apply"
across several groups can half-succeed and leave a folder holding a mix
of old and new tags. Auto-accept processes groups individually, so it
does not have that problem — but "an album is done" and "a group is
done" are different statements, and the entry points this issue adds
("Autotag this album" from a right-click) are album-shaped. Worth
deciding deliberately rather than inheriting.

#28 is up as PR #121, and it lands the shared half this issue asked for. Two things here rather than in the PR, since they are about *this* issue's remaining work. **The confidence tier is now one name.** `autotag.ConfidentTier` with `autotag.Confident(rec)` beside it, in `recommend.go`. This issue's "the two should agree on what high confidence means rather than computing it twice" is what it exists for, and the comment says so. What it deliberately does *not* try to be is the whole of auto-accept's test: the extra gates named above — exact track count, every normalized title matching, ±2 s, no cover-art replacement, no MBID conflict — cannot be expressed as a tier, so they stay this issue's to add on top. Reading `Confident(rec)` first and then applying them is the shape that keeps the two features honest with each other. **`MatchForAlbum` is a worked example of the no-extra-calls rule.** The rule stated here — "uses already-cached candidate data, no additional MusicBrainz calls" — is the same constraint the album page had, for a different reason (its lookup fires on page open, against limiters shared with every page the user can open). What it does: `lookupCachedCandidates(groupKey)` for the durable `tagging_candidates` blob, `LocalTracksForGroup` for the group, then `autotag.Recommend`. An unscored folder answers "nothing" rather than scoring itself. An auto-accept pass can read exactly the same way and skip a group the prefetch has not reached, which is also the behaviour that keeps it cancellable and restartable without losing work. One thing #28 could not settle and this issue will have to: it declines to act on an album that spans **more than one tagging group** (a multi-disc album is one group per disc), because a single "apply" across several groups can half-succeed and leave a folder holding a mix of old and new tags. Auto-accept processes groups individually, so it does not have that problem — but "an album is done" and "a group is done" are different statements, and the entry points this issue adds ("Autotag this album" from a right-click) are album-shaped. Worth deciding deliberately rather than inheriting.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Metadata Kind/Feature Platform/Desktop
Priority
Medium
3
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Blocks
#91 Autotag: a settings panel, and a way back from the dismissed file-write warning
yonlu/yellowjacket
Reference: yonlu/yellowjacket#90