Alert when an Apple Music account's session has gone stale #47

Merged
neerdoc merged 1 commit from macsome_6 into main 2026-07-28 09:39:30 +00:00
Owner

fetch_ma_playlists now tracks per-account attempted/failed counts for
every provider-backed (non-native) account touched in a sync, and flags
needs_reauth when every playlist attempted for an account failed (>=2
attempted, to distinguish a genuinely dead session from one persistently
odd playlist).

coordinator.py raises a persistent Home Assistant notification per
flagged account (stable notification_id per account instance, so it
doesn't re-spam every sync) and dismisses it automatically once that
account succeeds again. Exposed as sensor.tracks_owned's new "accounts"
attribute too.

This is a known, documented gap in Apple's own Music-User-Token design
(per Apple's developer relations: the token is meant to be re-derived per
session, not persisted long-term by a backend) rather than a Music
Assistant or music_own bug - confirmed via Apple Developer Forum reports
of the same days-not-months expiry when a token is stored server-side.
No code fix exists for the underlying expiry; this just makes it visible
immediately instead of requiring log-digging.

README updated with this context, plus the manual-token option (doesn't
change expiry, but sidesteps the browser-session-reuse risk when
re-authenticating a specific account since you can visually confirm which
account you're extracting the token from).

fetch_ma_playlists now tracks per-account attempted/failed counts for every provider-backed (non-native) account touched in a sync, and flags needs_reauth when every playlist attempted for an account failed (>=2 attempted, to distinguish a genuinely dead session from one persistently odd playlist). coordinator.py raises a persistent Home Assistant notification per flagged account (stable notification_id per account instance, so it doesn't re-spam every sync) and dismisses it automatically once that account succeeds again. Exposed as sensor.tracks_owned's new "accounts" attribute too. This is a known, documented gap in Apple's own Music-User-Token design (per Apple's developer relations: the token is meant to be re-derived per session, not persisted long-term by a backend) rather than a Music Assistant or music_own bug - confirmed via Apple Developer Forum reports of the same days-not-months expiry when a token is stored server-side. No code fix exists for the underlying expiry; this just makes it visible immediately instead of requiring log-digging. README updated with this context, plus the manual-token option (doesn't change expiry, but sidesteps the browser-session-reuse risk when re-authenticating a specific account since you can visually confirm which account you're extracting the token from).
fetch_ma_playlists now tracks per-account attempted/failed counts for
every provider-backed (non-native) account touched in a sync, and flags
needs_reauth when every playlist attempted for an account failed (>=2
attempted, to distinguish a genuinely dead session from one persistently
odd playlist).

coordinator.py raises a persistent Home Assistant notification per
flagged account (stable notification_id per account instance, so it
doesn't re-spam every sync) and dismisses it automatically once that
account succeeds again. Exposed as sensor.tracks_owned's new "accounts"
attribute too.

This is a known, documented gap in Apple's own Music-User-Token design
(per Apple's developer relations: the token is meant to be re-derived per
session, not persisted long-term by a backend) rather than a Music
Assistant or music_own bug - confirmed via Apple Developer Forum reports
of the same days-not-months expiry when a token is stored server-side.
No code fix exists for the underlying expiry; this just makes it visible
immediately instead of requiring log-digging.

README updated with this context, plus the manual-token option (doesn't
change expiry, but sidesteps the browser-session-reuse risk when
re-authenticating a specific account since you can visually confirm which
account you're extracting the token from).
Sign in to join this conversation.
No reviewers
No milestone
No project
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.

Dependencies

No dependencies set.

Reference
WulfScience-FOSS/ha-music-own!47
No description provided.