macsome_16 #57

Merged

neerdoc merged 5 commits from macsome_16 into main

2026-08-03 12:49:32 +00:00

neerdoc commented

2026-08-03 12:49:29 +00:00

Owner

No description provided.

neerdoc added 5 commits

2026-08-03 12:49:29 +00:00

Retry Plex search on apostrophe mismatch; raise the add-batch poll timeout cfa3fd277b

Two issues found directly from match_debug.log/wishlist_debug.log on a real
run:

1. Plex's title search can return 0 hits for a track you actually own.
   Confirmed live: "Queen - Don't Stop Me Now" (straight apostrophe, as
   Spotify/MA report it) got 0 Plex search hits despite being in the
   library — Plex's own indexed titles in the same log consistently use a
   curly apostrophe instead (e.g. "I'm a Fool for You Baby"), and Plex's
   search doesn't normalize the difference. _plex_find now retries once
   with the apostrophe swapped (straight<->curly) whenever the first
   search comes back empty.

2. The add-batch background-task poll was timing out too early and
   miscounting batches as failed. Confirmed live: of 6 Plex Wish List add
   batches in one run, only 1 reached "success" within the previous 60s
   timeout — the other 5 were still "pending"/"running" when polling gave
   up, at which point they get counted as failed even though they may
   well have finished shortly after (Apple's API is evidently slower than
   60s per batch of 25 under MA). Raised _TASK_POLL_TIMEOUT to 300s,
   slowed the poll interval accordingly, and added a periodic
   "still waiting" line to wishlist_debug.log so a long wait is visible
   instead of silent.

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

Log raw Apple search providers when the provider filter zeroes every result 454ef72157

Your NO APPLE MATCH sample showed something worth splitting into two
separate findings:

1. All 10 sampled tracks were logged with artist "Bernard Herrmann" despite
   being an unrelated batch of Christmas songs (Little Saint Nick, White
   Christmas, Auld Lang Syne, ...). That artist string comes straight from
   Music Assistant's own track.artists for these tracks (engine.py's
   extraction is a plain field read, nothing that could substitute one
   artist for another) — worth checking that source playlist directly in
   Music Assistant/Spotify to see whether it shows the same wrong artist
   there. If so this is upstream metadata corruption, not something to
   patch around here; a wrong-artist search was never going to resolve
   correctly regardless of the provider filter.

2. Separately, every sampled line showed 0 candidates out of a healthy
   19-25 total results — with zero candidates matching, we can't yet tell
   apart "genuinely no Apple match" from "provider_instance string doesn't
   match what search results report" (e.g. domain vs instance-id) without
   more evidence. When the provider filter zeroes out every result,
   _apple_resolve_uri now also logs the raw distinct provider values MA
   actually returned, so the next run's wishlist_debug.log answers that
   directly instead of needing another guess.

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

Sweep pre-existing wanted rows against Plex even if their playlist is gone 0ae77beb61

Confirmed live: "Scooter - Fire" was owned in Plex and sitting in the Apple
Music Wish List, with zero mentions anywhere in match_debug.log for that
entire run. The only way that's possible is if the track wasn't in any of
the playlists being synced anymore — every existing cleanup (including the
last several rounds of fixes) only clears a wanted row as a side effect of
re-encountering the same track in a *currently-synced* playlist and
matching it there. A track whose source playlist was removed/renamed, or
that simply fell out of it, never gets that chance, so the row just sits
in `wanted` forever regardless of whether it's since been bought or added
to Plex by other means.

_sweep_stale_wanted() closes that gap: after the per-playlist loop, every
wanted row older than this run's start gets re-checked against Plex
directly (not tied to any playlist), and cleared if it now matches. Rows
inserted during this same run are skipped since they were just checked.
This doesn't re-add anything to a Plex playlist (we no longer know which
one it "belongs" to) — it only corrects the wanted/buylist bookkeeping.

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

Refresh stale wanted-row text on every run instead of freezing it at first insert d96e03eed4

Direct DB proof: the wanted row for "Little Saint Nick" (key
USCA29800605@@Köpt musik) has artist='Bernard Herrmann' stored, while
match_debug.log shows the *same* track, same isrc, same playlist, freshly
computed this run as 'Various Artists'. Both can't be what MA reports now
— the DB row is frozen at whatever was captured the very first time this
key was ever inserted, because the insert was `INSERT OR IGNORE`: once a
key exists, every later run that still can't match it leaves the stored
artist/title/album/isrc/uri untouched, no matter what _plex_find (and now
_apple_resolve_uri) compute fresh from live MA data every single run.

This is bigger than one Christmas playlist: any row created while one of
the matching bugs fixed earlier this branch (multi-artist dilution, no
originalTitle fallback, etc.) was still active is permanently stuck with
whatever bad text that produced, even though a fresh run today would get
it right. New rows were never affected — only ones that already existed
before today's fix landed.

Switched to INSERT ... ON CONFLICT(key) DO UPDATE, refreshing artist,
title, album, isrc, uri, and the qobuz_* lookup fields (already
recomputed fresh every run regardless, previously just discarded by OR
IGNORE) on every run a row is still unmatched. added_at is deliberately
left out of the UPDATE so it keeps reflecting original discovery time,
which the stale-row sweep depends on.

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

Add "Fill missing album tracks" — find album gaps via MusicBrainz, add to buy-list 917493ef8b

New button/coordinator entrypoint, separate from the regular scheduled
sync: for every album in Plex that Plex has online-matched to a specific
MusicBrainz release (a real mbid in the album's guids — one extra Plex API
call per album to reload() and read it), fetches that release's canonical
tracklist from MusicBrainz and adds any track present on the release but
missing from the Plex album to the wanted store, same as a gap found via
a source playlist.

Albums Plex hasn't online-matched are skipped outright — there's no
reliable canonical tracklist to diff against without guessing which
regional/reissue edition applies, which is exactly the ambiguity
_plex_find already fights (confirmed firsthand tonight with the 3 Doors
Down "missing Kryptonite" example: MusicBrainz has many editions of the
same album with different tracklists).

Deliberately its own manually-triggered operation rather than part of
full_sync(): MusicBrainz asks for ~1 request/second, so a full-library
sweep across potentially thousands of albums is a genuinely slow,
occasional operation, not something to run on every scheduled sync.
Shares the coordinator's sync lock/cancel event with full_sync() since
both write to the wanted table.

Tracks found this way have no MA-sourced URI (there's no source playlist
to draw one from), so this also extends sync_wishlist_playlist() to
resolve those against Apple Music directly by artist/title via
_apple_resolve_uri() (new tracks_missing_uri()/record_resolved_uris()
helpers), the same mechanism already used for foreign-provider URI
translation — newly resolved URIs get persisted onto the wanted row so
future runs don't re-resolve the same track from scratch.

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

neerdoc merged commit 398be646b1 into main

2026-08-03 12:49:32 +00:00

neerdoc referenced this pull request from a commit

2026-08-03 12:49:32 +00:00

Merge pull request 'macsome_16' (#57) from macsome_16 into main