Resolve buy-list tracks to a native Apple Music URI before adding to the wishlist #56

Merged

neerdoc merged 1 commit from macsome_15 into main

2026-08-02 21:22:49 +00:00

neerdoc commented

2026-08-02 21:22:45 +00:00

Owner

Adds _apple_resolve_uri(), which searches that Apple Music account
directly (client.music.search(), filtered to its provider instance,
fuzzy-scored the same way _plex_find/_qobuz_search already are) and
resolves each buy-list track to its native URI before adding, the same
way _qobuz_search already resolves a purchase link instead of trusting
cross-catalogue translation. Falls back to the original URI when nothing
resolves, so this can't regress below current behavior. The existing
current/desired diffing (to_add/stale) still keys off the original URIs
since that's what matches across runs.

Per-track artist/title needed for the search comes from a new
uri_track_index() — _buylist() collapses album-grouped entries and loses
per-track detail, so this reads the flat wanted rows directly.

Also extends the per-track match diagnostics (macsome_14) with Plex's
guid field on every candidate, to find out empirically whether this
library's tracks carry a cross-referenceable Plex catalog match we could
use as a stronger signal than fuzzy text — and adds a second log,
wishlist_debug.log, covering every resolve attempt and add-batch outcome
for this stage.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

Manual audits kept finding most "wanted" tracks already in Plex despite the last several matching fixes, and separately, a batch reported as "194 added, 0 failed" only had 90 tracks actually land in the real Apple Music playlist. Root cause for the second part: add_playlist_tracks is fed whatever URI the source playlist used (Spotify, etc.), and MA's task status reports "success" without ever confirming that foreign-provider URI actually resolved into a real entry on the Apple Music account that owns "Plex Wish List" — so roughly half the adds were silently no-ops. Adds _apple_resolve_uri(), which searches that Apple Music account directly (client.music.search(), filtered to its provider instance, fuzzy-scored the same way _plex_find/_qobuz_search already are) and resolves each buy-list track to its native URI before adding, the same way _qobuz_search already resolves a purchase link instead of trusting cross-catalogue translation. Falls back to the original URI when nothing resolves, so this can't regress below current behavior. The existing current/desired diffing (to_add/stale) still keys off the original URIs since that's what matches across runs. Per-track artist/title needed for the search comes from a new uri_track_index() — _buylist() collapses album-grouped entries and loses per-track detail, so this reads the flat wanted rows directly. Also extends the per-track match diagnostics (macsome_14) with Plex's `guid` field on every candidate, to find out empirically whether this library's tracks carry a cross-referenceable Plex catalog match we could use as a stronger signal than fuzzy text — and adds a second log, wishlist_debug.log, covering every resolve attempt and add-batch outcome for this stage. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

neerdoc added 1 commit

2026-08-02 21:22:45 +00:00

Resolve buy-list tracks to a native Apple Music URI before adding to the wishlist d46b804c82

Manual audits kept finding most "wanted" tracks already in Plex despite
the last several matching fixes, and separately, a batch reported as
"194 added, 0 failed" only had 90 tracks actually land in the real Apple
Music playlist. Root cause for the second part: add_playlist_tracks is
fed whatever URI the source playlist used (Spotify, etc.), and MA's task
status reports "success" without ever confirming that foreign-provider
URI actually resolved into a real entry on the Apple Music account that
owns "Plex Wish List" — so roughly half the adds were silently no-ops.

Adds _apple_resolve_uri(), which searches that Apple Music account
directly (client.music.search(), filtered to its provider instance,
fuzzy-scored the same way _plex_find/_qobuz_search already are) and
resolves each buy-list track to its native URI before adding, the same
way _qobuz_search already resolves a purchase link instead of trusting
cross-catalogue translation. Falls back to the original URI when nothing
resolves, so this can't regress below current behavior. The existing
current/desired diffing (to_add/stale) still keys off the original URIs
since that's what matches across runs.

Per-track artist/title needed for the search comes from a new
uri_track_index() — _buylist() collapses album-grouped entries and loses
per-track detail, so this reads the flat wanted rows directly.

Also extends the per-track match diagnostics (macsome_14) with Plex's
`guid` field on every candidate, to find out empirically whether this
library's tracks carry a cross-referenceable Plex catalog match we could
use as a stronger signal than fuzzy text — and adds a second log,
wishlist_debug.log, covering every resolve attempt and add-batch outcome
for this stage.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

neerdoc merged commit 2857caea95 into main

2026-08-02 21:22:49 +00:00

neerdoc referenced this pull request from a commit

2026-08-02 21:22:51 +00:00

Merge pull request 'Resolve buy-list tracks to a native Apple Music URI before adding to the wishlist' (#56) from macsome_15 into main