v6.5.3-beta.2

Second test build for the #54/#56/#57 train (do not use in production).

New since v6.5.3-beta.1

February 2026 Spotify API migrations (#57)

• like_media/unlike_media now use PUT/DELETE /me/library (replacement for the removed /me/tracks write endpoints; verified live, works for both old and new client ids)
• Playlist track listing now uses GET /playlists/{id}/items (replacement for the removed /tracks route)
• Removed dead async_get_artist_top_tracks (endpoint removed by Spotify with no replacement, was unused)
• spotcast/categories websocket endpoint returns an empty list with a warning instead of erroring on client ids that no longer have browse categories

Device filtering + stale purge (#56)

New per-account options (Settings > Devices & services > Spotcast > Configure):

• Days before removing unavailable devices (default 7, 0 = immediately)
• Device filter mode (deny/allow) + Device filter patterns (comma-separated, case-insensitive, e.g. *Jam*)

The stale purge now persists across restarts and also cleans up devices left over from previous versions: restored media_player entities whose device Spotify no longer reports start aging immediately and are removed from the registries once past the timeout.

Carried over from beta.1

• Cached playlists/liked-songs count calls (~40% fewer steady-state API requests)
• Honest "Spotify API temporarily unavailable (server errors)" message instead of spotipy's fake 429
• No duplicate error log per failed refresh

Testing focus

1. Options dialog shows the three new fields; set timeout to 0 or 1 day and add a deny pattern matching a known stale device name, confirm entity/device disappear on the next cycles.
2. Restart HA: previously-unavailable devices should keep aging (check .storage/spotcast_<entry>_device_staleness).
3. like_media/unlike_media still work (now on /me/library).
4. Zombie devices from older versions (e.g. old Jam entries) get purged once past the timeout.