4grayandClaude Fable 5.1 89beb2c4a5 fix(xtream): guard the account-info answer by playlist identity and reject rolled-over dates ...

Review follow-ups (Greptile):

- A source switch while `get_account_info` is in flight no longer hands
  playlist A's status or clock to playlist B: the store is patched only
  while the asking playlist is still selected, the timezone is persisted
  under the asking playlist's id regardless, and a late failure cannot mark
  the newly selected playlist unavailable.
- `parseNaiveUtcMs` reads the constructed date back, so out-of-range panel
  strings (`2026-13-01 25:00:00`) are rejected instead of silently rolling
  over into a real instant.
- Document that a clock-derived fixed offset is a DST-less snapshot, refreshed
  by every account-info check and only ever used for non-standard servers.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

2026-09-06 23:20:54 +02:00

..

architecture

fix(xtream): guard the account-info answer by playlist identity and reject rolled-over dates

2026-09-06 23:20:54 +02:00

superpowers

feat(epg): rebuild the programme guide for M3U playlists (#1560)

2026-09-06 18:47:25 +02:00