macsome_5 #46

Merged

neerdoc merged 2 commits from macsome_5 into main

2026-07-28 06:34:33 +00:00

neerdoc commented

2026-07-28 06:34:29 +00:00

Owner

No description provided.

neerdoc added 2 commits

2026-07-28 06:34:29 +00:00

Pace playlist track fetches to avoid tripping the provider's rate limiter f209e45272

Live evidence: both connected Apple Music accounts got an identical 403 on
music.apple.com/v1/me/library/playlists/.../tracks during a full sync (111
playlists fetched back-to-back with zero delay between calls), while a
single manual "sync now" triggered from Music Assistant's own UI succeeded
for the same playlists. Confirmed via MA's own controller source
(controllers/music/media/playlists.py) that playlist tracks are never
persisted in MA's database - every read, ours or MA's own, makes a live
call to the provider - so request volume/pacing is the most likely
differentiator, not a per-account auth issue.

Adds a 300ms delay after each provider-backed (non-native) playlist's
track fetch, matching the pacing already used for Qobuz calls elsewhere in
this file. This is a hypothesis-driven mitigation, not a confirmed root
cause - if 403s persist even with pacing, the next thing to check is
Music Assistant's own server logs at the failure timestamps for explicit
rate-limit (429) messages.

Fetch playlist tracks via the specific provider mapping, not MA's ambiguous auto-resolution 1f7b1496a5

The previous rate-limit theory for the 403s didn't hold up (other
playlists on the same account succeeded in the same tight window - not
consistent with account-level throttling), so the pacing delay from the
last commit is removed here as unjustified.

Root cause, confirmed by reading Music Assistant's own
controllers/music/media/base.py: when we call get_playlist_tracks with
item_id="library" (which we always did, since that's what worked for the
vast majority of playlists), the server's _select_provider_id() resolves
the actual account to use - and when there's no per-user provider_filter
set (our situation exactly, since music_own is a plain API client, not
one of MA's "users"), it just does `next(iter(provider_mappings))`: the
first mapping in whatever order they happen to be stored, with zero
account awareness. If a library item ends up mapped to both Apple Music
accounts, MA can and will send one account's item id using the other
account's token - a deterministic 403 for that specific playlist, not a
transient error, exactly matching what two different sync runs on two
different days showed for the same playlist IDs.

Fix: use the specific (provider_instance, item_id) pair we already
resolve ourselves from provider_mappings for the track fetch, instead of
delegating account selection to MA's ambiguous fallback. Native
(non-provider-backed) playlists are unaffected - they still use
pl.item_id/"library" since there's no external mapping to pick from.

neerdoc merged commit f17d59759f into main

2026-07-28 06:34:33 +00:00

neerdoc referenced this pull request from a commit

2026-07-28 06:34:34 +00:00

Merge pull request 'macsome_5' (#46) from macsome_5 into main