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

Desktop: surface a high-confidence autotag match on the album/artist/track page, with a one-click apply #28

New Issue
Closed
opened 2026-08-18 05:55:00 +00:00 by logan · 0 comments
logan commented 2026-08-18 05:55:00 +00:00
Collaborator
Copy Link
Copy Source

Report

If the autotagger has a high-confidence match for an album/track/artist, I want to be told while I am looking at that thing, with a call to action — open it in the autotagger, or better, apply it right there and watch the page fill in with metadata. Today I have to notice the metadata is missing, then go hunt the album down on the Autotag page.

Findings

  • The matching and scoring live in the autotag backend; the apply path is a registered job (jobs), and rewriting tags emits TrackMetadataChanged — the most expensive event in the app, which makes library-store discard every cached collection and refetch. A one-click apply from a detail page will pay that, which is correct but should be expected.
  • The apply is an irreversible on-disk metadata rewrite, so it goes behind confirmAction() with an honest impact line — and a folder left holding a mix of old and new tags is exactly the Blocking-level notification case already documented.
  • explore-album-details already knows whether it is looking at an untagged/library-only album (catalogPending/catalogLoaded, catalog-scope-notice), which is the natural place to hang this.

Direction

  1. A backend query: "is there a high-confidence match for this album/artist/track", cheap enough to call on page open (or answered from an existing autotag candidate cache rather than a fresh MusicBrainz round trip — the rate limiters are shared with every page the user can open, and a background lane exists for exactly this).
  2. A catalog-scope-notice-style banner: "MusicBrainz has a match for this album (95%)" with "Review in Autotag" and "Apply tags".
  3. Define the confidence threshold once, in the backend, so the badge and the autotag page cannot disagree.
**Report** If the autotagger has a high-confidence match for an album/track/artist, I want to be told while I am *looking at that thing*, with a call to action — open it in the autotagger, or better, apply it right there and watch the page fill in with metadata. Today I have to notice the metadata is missing, then go hunt the album down on the Autotag page. **Findings** - The matching and scoring live in the autotag backend; the apply path is a registered job (`jobs`), and rewriting tags emits `TrackMetadataChanged` — the most expensive event in the app, which makes `library-store` discard every cached collection and refetch. A one-click apply from a detail page will pay that, which is correct but should be expected. - The apply is an irreversible on-disk metadata rewrite, so it goes behind `confirmAction()` with an honest impact line — and a folder left holding a mix of old and new tags is exactly the Blocking-level notification case already documented. - `explore-album-details` already knows whether it is looking at an untagged/library-only album (`catalogPending`/`catalogLoaded`, `catalog-scope-notice`), which is the natural place to hang this. **Direction** 1. A backend query: "is there a high-confidence match for this album/artist/track", cheap enough to call on page open (or answered from an existing autotag candidate cache rather than a fresh MusicBrainz round trip — the rate limiters are shared with every page the user can open, and a background lane exists for exactly this). 2. A `catalog-scope-notice`-style banner: "MusicBrainz has a match for this album (95%)" with "Review in Autotag" and "Apply tags". 3. Define the confidence threshold once, in the backend, so the badge and the autotag page cannot disagree.
logan added the Area/MetadataKind/FeaturePlatform/Desktop
Priority
Medium
3
 labels 2026-08-18 14:36:08 +00:00
logan closed this issue 2026-08-19 06:49:49 +00:00
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
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#28