SBDeveloper/medley
Watch
1
0
Fork
You've already forked medley
 0
Code Issues 6 Pull requests Releases 5 Activity Actions

Track matching: ISRC merge with preferred Source #29

New issue
Closed
opened 2026-10-06 21:16:53 +02:00 by SBDeveloper · 1 comment
SBDeveloper commented 2026-10-06 21:16:53 +02:00
Owner
Copy link

Part of #13

What to build

With matching enabled, Library Tracks from different Sources that share an ISRC are grouped into one Recording (see ADR 0003). The Library shows one entry per Recording with its Source badges. The Recording plays the highest-ranked available Track by Source ranking, which the user can set, with a per-Recording pin to override. Tracks stay single-Source: Playlists, the Queue and Favourites keep holding plain Tracks, and Source Playlists are unaffected. When a Playlist or Queue entry's Track is unavailable, playback falls back to the next-ranked Track of its Recording and shows which one plays. Matching is opt-in; v1 separate-Tracks behaviour is the default. Sources expose an optional ISRC on Track metadata (local files read it from tags). Library Tracks only; no Catalog results, albums or artists.

Acceptance criteria

  • Opt-in matching setting in Core
  • Optional ISRC on Track metadata from the Deezer and local-files Sources
  • Same-ISRC Library Tracks form one Recording; Recordings with one Track look like normal entries
  • Source ranking setting and per-Recording pin decide which Track plays
  • Playlist and Queue entries fall back to the next-ranked Recording Track when unavailable
  • Favourites, Playlists and Source Playlists behave unchanged
  • Core integration tests with two fake Sources

Blocked by

Part of #13 ## What to build With matching enabled, Library Tracks from different Sources that share an ISRC are grouped into one **Recording** (see ADR 0003). The Library shows one entry per Recording with its Source badges. The Recording plays the highest-ranked available Track by **Source ranking**, which the user can set, with a per-Recording pin to override. Tracks stay single-Source: Playlists, the Queue and Favourites keep holding plain Tracks, and Source Playlists are unaffected. When a Playlist or Queue entry's Track is unavailable, playback falls back to the next-ranked Track of its Recording and shows which one plays. Matching is opt-in; v1 separate-Tracks behaviour is the default. Sources expose an optional ISRC on Track metadata (local files read it from tags). Library Tracks only; no Catalog results, albums or artists. ## Acceptance criteria - [ ] Opt-in matching setting in Core - [ ] Optional ISRC on Track metadata from the Deezer and local-files Sources - [ ] Same-ISRC Library Tracks form one Recording; Recordings with one Track look like normal entries - [ ] Source ranking setting and per-Recording pin decide which Track plays - [ ] Playlist and Queue entries fall back to the next-ranked Recording Track when unavailable - [ ] Favourites, Playlists and Source Playlists behave unchanged - [ ] Core integration tests with two fake Sources ## Blocked by - #14
SBDeveloper commented 2026-10-07 21:18:20 +02:00
Author
Owner
Copy link

Core done in b3e0270 + follow-up. Not done: Library UI (grouped entries, Source badges, ranking/pin/matching settings); Tauri commands and core.ts bindings exist. Queue shows the playing Track via playback state only.

Core done in b3e0270 + follow-up. Not done: Library UI (grouped entries, Source badges, ranking/pin/matching settings); Tauri commands and core.ts bindings exist. Queue shows the playing Track via playback state only.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.3.0
v0.2.1
v0.2.0
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels   
bug
Something is broken

  
enhancement
New feature or improvement

  
needs-info
Waiting on reporter for more information

  
needs-triage
Maintainer needs to evaluate this issue

  
ready-for-agent
Fully specified, ready for an AFK agent

  
ready-for-human
Requires human implementation

  
wontfix
Will not be actioned

No labels
bug
enhancement
needs-info
needs-triage
ready-for-agent
ready-for-human
wontfix
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#30 Track matching: fuzzy fallback, Source fallback and un-merge
SBDeveloper/medley
Depends on
#14 Decide Track matching semantics (ADR + glossary)
SBDeveloper/medley
Reference
SBDeveloper/medley#29
No description provided.