feat(library): sort and badge by personal difficulty rating - #810
Merged
byrongamatos merged 3 commits intoJul 7, 2026
Merged
Conversation
Adds sort=difficulty/difficulty-desc to the library API (correlated subquery over song_user_meta.user_difficulty, unrated songs pushed to the bottom either direction, same pattern as the existing mastery sort) and surfaces the rating as a badge on library cards in both the v2 grid/tree views and the v3 grid. The rating itself already existed (song_user_meta) — this just makes it sortable and visible, so it's no longer only readable in the per-song edit drawer. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds personal difficulty sorting to the library, tree-view song enrichment, and frontend sort options plus difficulty badges in grid and list views. ChangesDifficulty Sorting Feature
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…tests - Wrap song.user_difficulty in esc() at both badge call sites (static/app.js ~2082 and ~2283) for XSS-consistency with the sibling tuning badge, which already uses esc(). - server.py: query_artists (the classic tree view's data source, used by /api/library/artists) never batch-attached user_difficulty the way query_page does for the grid, so the tree-view difficulty badge added in 75673c3 was unreachable dead code (song.user_difficulty was always undefined there). Now attaches it via the existing user_meta_map() helper, same pattern as query_page. - Add an [Unreleased] CHANGELOG.md entry for the difficulty sort + badge feature, matching the repo's existing entry format. - Add tests/test_library_filters.py::test_difficulty_sort_pushes_unrated_to_bottom asserting unrated songs sort to the bottom in both sort=difficulty and sort=difficulty-desc directions, and ::test_tree_view_songs_carry_user_difficulty covering the query_artists fix above. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@server.py`:
- Around line 4396-4400: The user_meta_map call in query_artists is batching too
many song IDs into a single IN query and can exceed SQLite’s older variable
limit for prolific artists. Update query_artists to split the rows into the same
400-row batches used by overrides_map, and call user_meta_map per batch before
merging the results so the difficulty badge logic still works without hitting
placeholder limits.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 4586a437-2e7b-480c-823a-71454fc310dc
📒 Files selected for processing (4)
CHANGELOG.mdserver.pystatic/app.jstests/test_library_filters.py
✅ Files skipped from review due to trivial changes (1)
- CHANGELOG.md
🚧 Files skipped from review as they are similar to previous changes (1)
- static/app.js
Address review-bot findings on the difficulty sort/badge: - user_meta_map now chunks filenames into 400-row batches (like overrides_map) before the IN (...) query. query_artists (tree view) passes every song across up to 50 artists, which could push the placeholder count past SQLite's older variable limit; query_page's small pages are unaffected. (CodeRabbit: Stability & Availability) - Rebuild static/tailwind.min.css: the ◆N difficulty badge introduced bg-blue-900/30 + text-blue-300, which were never compiled into the committed stylesheet, failing the tailwind-fresh CI gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
topkoa
added a commit
that referenced
this pull request
Jul 19, 2026
Finding un-split songs took five taps (cycle each stem pill to its "lacks" state) — and was quietly wrong even then: the drawer offered five of the canonical six stems, so a piano-only song lacked all five listed and matched a hand-built "not split" filter despite being split. The stems section gains a "Not split" toggle that sets stem_lacks to every instrument stem in one tap (the same lacks-ALL query Stem Splitter's missing-stems view runs, backend semantics unchanged), and piano joins the pill row (already in the backend's allowed set). (Rebuilt on current main after #1003/#810/#92e78be rewrote the drawer region — the original branch conflicted whole-file.) Signed-off-by: topkoa <topkoa@gmail.com>
topkoa
added a commit
that referenced
this pull request
Jul 19, 2026
Finding un-split songs took five taps (cycle each stem pill to its "lacks" state) — and was quietly wrong even then: the drawer offered five of the canonical six stems, so a piano-only song lacked all five listed and matched a hand-built "not split" filter despite being split. The stems section gains a "Not split" toggle that sets stem_lacks to every instrument stem in one tap (the same lacks-ALL query Stem Splitter's missing-stems view runs, backend semantics unchanged), and piano joins the pill row (already in the backend's allowed set). (Rebuilt on current main after #1003/#810/#92e78be rewrote the drawer region — the original branch conflicted whole-file.) Signed-off-by: topkoa <topkoa@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
sort=difficulty/sort=difficulty-descto the library API — a correlated subquery oversong_user_meta.user_difficulty, following the same pattern as the existingmasterysort (unrated songs pushed to the bottom in both directions).◆Nbadge on library cards, in both the v2 grid/tree views and the v3 grid.The rating itself (
song_user_meta.user_difficulty) already existed and was editable in the per-song details drawer — this just makes it sortable and visible at a glance in the main library, so it's no longer something you can only see by opening each song individually.Built as a companion to a new community plugin (difficulty_tagger) that auto-seeds this rating from chart analysis, but this PR has no dependency on it — it works the same whether the rating was set manually or by any plugin.
Test plan
pytestsuite passes (2318 passed, 4 skipped)sort=difficulty-desccorrectly surfaces known-hard songs first,sort=difficultysurfaces the built-in beginner tutorial pak firstSummary by CodeRabbit