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

Sort albums by completeness — needs the answer moved out of the per-screenful store #184

New Issue
Open
opened 2026-08-21 14:22:38 +00:00 by yonlu · 0 comments
yonlu commented 2026-08-21 14:22:38 +00:00
Owner
Copy Link
Copy Source

Report

"Which albums am I missing tracks from" is a question the app can
already answer per card, and cannot answer as a sort key.

store/completeness-store.ts batches GetAlbumsCompleteness for a
screenful — request() is per-card and coalesces into one call per
frame, because a virtualized list cannot hand over "the whole list".
That is the right shape for drawing a badge and the wrong shape for
sorting: a sort key must be answerable for every row before the first
row renders, not for the ~30 on screen.

Findings

  • cover-grid has three sort keys today (name, artist, year) and
    library.Album carries no completeness information at all.
  • The numerator is local (distinct track numbers on disk) and the
    denominator is the files' own per-disc total_tracks, falling back to
    explore_index.total_tracks. completenessAnswer() is where the two
    merge.
  • Known is a third state: a great deal of any library declares no
    total, and those albums must not sort as 0% — they are not incomplete,
    they are unanswered. Any ordering has to put them somewhere
    deliberate (probably last, in both directions).
  • Partly gated on the catalog half: no published artifact carries
    total_tracks yet, so until one does the only answers come from
    files that declare their own totals.

Direction

Move the answer into the album projection — GetAlbums returning
owned/expected/known per album — so the grid has it for every row, and
have completeness-store read from that rather than asking per card.
That is a real change to how the badge is fed, not an addition beside
it, which is why this is its own issue rather than part of the sort-key
work in #32/#46.

Worth confirming the cost first: it is one more aggregate in a query
that already groups over audio_files, against thousands of albums
rather than 50k tracks, so it is plausibly cheap enough to be
unconditional. Measure before committing to the lazy-store removal.

**Report** "Which albums am I missing tracks from" is a question the app can already answer per card, and cannot answer as a sort key. `store/completeness-store.ts` batches `GetAlbumsCompleteness` for a screenful — `request()` is per-card and coalesces into one call per frame, because a virtualized list cannot hand over "the whole list". That is the right shape for drawing a badge and the wrong shape for sorting: **a sort key must be answerable for every row before the first row renders**, not for the ~30 on screen. **Findings** - `cover-grid` has three sort keys today (name, artist, year) and `library.Album` carries no completeness information at all. - The numerator is local (distinct track numbers on disk) and the denominator is the files' own per-disc `total_tracks`, falling back to `explore_index.total_tracks`. `completenessAnswer()` is where the two merge. - `Known` is a third state: a great deal of any library declares no total, and those albums must not sort as 0% — they are not incomplete, they are unanswered. Any ordering has to put them somewhere deliberate (probably last, in both directions). - Partly gated on the catalog half: no published artifact carries `total_tracks` yet, so until one does the only answers come from files that declare their own totals. **Direction** Move the answer into the album projection — `GetAlbums` returning owned/expected/known per album — so the grid has it for every row, and have `completeness-store` read from that rather than asking per card. That is a real change to how the badge is fed, not an addition beside it, which is why this is its own issue rather than part of the sort-key work in #32/#46. Worth confirming the cost first: it is one more aggregate in a query that already groups over `audio_files`, against thousands of albums rather than 50k tracks, so it is plausibly cheap enough to be unconditional. Measure before committing to the lazy-store removal.
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/Library-UI Kind/Feature Platform/Android Platform/Desktop
Priority
Low
4
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#184