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

Desktop: album detail should be able to show the full catalog tracklist, including tracks I do not have #7

New Issue
Closed
opened 2026-08-18 05:53:05 +00:00 by logan · 1 comment
logan commented 2026-08-18 05:53:05 +00:00
Collaborator
Copy Link
Copy Source

Report

When an album says "1 of 15 tracks in [album] are in your library", that tells me the metadata exists, that I am missing tracks, and that YellowJacket knows which. But the page only shows the tracks I have. I want to see the full album with the missing tracks marked.

Findings

  • This is supposed to work already: explore-album-details.buildLibraryEntry shows the catalog's tracklist with the missing rows dimmed — but it is guarded on completeness.known, i.e. on the files declaring a per-disc total_tracks.
  • Where the tags declare no total, explore_index.total_tracks is the fallback (completenessAnswer()), and an artifact built before that column exists reports 0 ("the catalog does not say").
  • Existing databases read "unknown" until a rescan repopulates audio_files.total_tracks, and our own tagwriter writes track/disc numbers but not totals — so autotagging currently degrades the field this rests on.

Direction

Two parts, and the second is probably the real ask:

  1. Make the full-tracklist view available whenever a catalog tracklist exists, not only when completeness is known — e.g. an explicit toggle ("Show full album" / "Only my tracks") so it does not depend on tag quality at all.
  2. Fix the inputs so the automatic case fires more often: have tagwriter write track/disc totals, and confirm the shipped artifact carries total_tracks.

Related: the ownership-badge inconsistency issue, and the "make unowned content obvious" issue.

**Report** When an album says "1 of 15 tracks in [album] are in your library", that tells me the metadata exists, that I am missing tracks, and that YellowJacket knows which. But the page only shows the tracks I have. I want to see the full album with the missing tracks marked. **Findings** - This is supposed to work already: `explore-album-details.buildLibraryEntry` shows the *catalog's* tracklist with the missing rows dimmed — but it is guarded on `completeness.known`, i.e. on the files declaring a per-disc `total_tracks`. - Where the tags declare no total, `explore_index.total_tracks` is the fallback (`completenessAnswer()`), and an artifact built before that column exists reports 0 ("the catalog does not say"). - Existing databases read "unknown" until a rescan repopulates `audio_files.total_tracks`, and our own `tagwriter` writes track/disc *numbers* but not totals — so autotagging currently degrades the field this rests on. **Direction** Two parts, and the second is probably the real ask: 1. Make the full-tracklist view available whenever a catalog tracklist exists, not only when completeness is `known` — e.g. an explicit toggle ("Show full album" / "Only my tracks") so it does not depend on tag quality at all. 2. Fix the inputs so the automatic case fires more often: have `tagwriter` write track/disc totals, and confirm the shipped artifact carries `total_tracks`. Related: the ownership-badge inconsistency issue, and the "make unowned content obvious" issue.
logan self-assigned this 2026-08-19 00:37:58 +00:00
logan added
Status
In Progress
 and removed
Status
Blocked
1
 labels 2026-08-19 00:37:59 +00:00
logan commented 2026-08-19 00:37:59 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming this. Branch: feat/7-full-tracklist-toggle. Unblocked by #16, which is merged.

On Direction part 2 — half of it was #16: tagwriter now writes the per-disc totals, so autotagging stops degrading the field the automatic rule rests on.

The other half was "confirm the shipped artifact carries total_tracks". It does not. Measured just now against the live artifact:

$ curl -sSI .../generic/yellowjacket-core-index/latest/core-index.db.zst
last-modified: Mon, 10 Aug 2026 04:38:16 GMT
content-length: 75417037

$ sqlite3 core-index.db \
    "SELECT COUNT(*) FROM pragma_table_info('explore_index') WHERE name='total_tracks';"
0
$ sqlite3 core-index.db "SELECT COUNT(*) FROM explore_index;"
1079667

The column landed in the schema on 2026-08-16 (feat(database): shape the library like files, and shrink the catalog); the published artifact is from 08-10. So completenessAnswer()'s catalog fallback answers 0 for every user today — the machinery is correct and artifactHasTotals() is doing exactly its job, there is simply no data behind it yet. It rides along on the next publish, which is #88's ask. Noted there.

That is the argument for Direction part 1 being "probably the real ask", and it is what I am implementing: the automatic route depends on two inputs, one of which is tag quality and the other of which is a monthly artifact. An explicit control depends on neither.

Approach. A "Show the whole album" switch above the tracklist, which flips the synthetic "Your Library" entry between the local files and the catalog release with the missing rows dimmed — the rendering the page could already do but could only be triggered by completeness.known.

State is tri-state (null = follow the automatic rule), so the switch agrees with the page rather than starting out contradicting it, and the user outranks it either way. It appears only where it can change what is on screen: against the library entry, with a catalog release to switch to, and only when the two tracklists differ — the same test the version dropdown answers.

Claiming this. Branch: `feat/7-full-tracklist-toggle`. Unblocked by #16, which is merged. **On Direction part 2** — half of it was #16: `tagwriter` now writes the per-disc totals, so autotagging stops degrading the field the automatic rule rests on. The other half was "confirm the shipped artifact carries `total_tracks`". **It does not.** Measured just now against the live artifact: ``` $ curl -sSI .../generic/yellowjacket-core-index/latest/core-index.db.zst last-modified: Mon, 10 Aug 2026 04:38:16 GMT content-length: 75417037 $ sqlite3 core-index.db \ "SELECT COUNT(*) FROM pragma_table_info('explore_index') WHERE name='total_tracks';" 0 $ sqlite3 core-index.db "SELECT COUNT(*) FROM explore_index;" 1079667 ``` The column landed in the schema on 2026-08-16 (`feat(database): shape the library like files, and shrink the catalog`); the published artifact is from 08-10. So `completenessAnswer()`'s catalog fallback answers 0 for **every** user today — the machinery is correct and `artifactHasTotals()` is doing exactly its job, there is simply no data behind it yet. It rides along on the next publish, which is #88's ask. Noted there. That is the argument for Direction part 1 being "probably the real ask", and it is what I am implementing: the automatic route depends on two inputs, one of which is tag quality and the other of which is a monthly artifact. An explicit control depends on neither. **Approach.** A "Show the whole album" switch above the tracklist, which flips the synthetic "Your Library" entry between the local files and the catalog release with the missing rows dimmed — the rendering the page could already do but could only be *triggered* by `completeness.known`. State is tri-state (`null` = follow the automatic rule), so the switch agrees with the page rather than starting out contradicting it, and the user outranks it either way. It appears only where it can change what is on screen: against the library entry, with a catalog release to switch to, and only when the two tracklists differ — the same test the version dropdown answers.
logan closed this issue 2026-08-19 01:10:34 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-19 01:10:42 +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/Explore Area/Metadata Kind/Enhancement Platform/Desktop
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Depends on
#16 Desktop: album ownership badge says "in your library" for an album I hold 2 of 10 tracks of
yonlu/yellowjacket
Reference: yonlu/yellowjacket#7