mirror of
https://github.com/4gray/iptvnator.git
synced 2026-10-08 17:06:15 -08:00
4grayandClaude Opus 4.7
888a2dd80a
Opening the playlist switcher fired one XTREAM_REQUEST IPC + HTTPS round-trip per Xtream playlist and only updated the UI after ALL of them resolved. A single slow or hung portal pinned every status dot in the menu to the misleading red 'unavailable' state for the full tail latency (often several seconds, sometimes longer). Four changes land together: 1. Stream results — each portal's dot updates via signal.update() the moment ITS request resolves, independent of the slowest one. The previous Promise.all wrote a single Map at the end; now the Map grows incrementally. 2. New 'checking' status — extends PortalStatus with a pulsing-dot visual so users see "we're working on it" instead of red dots that look like failures. Respects prefers-reduced-motion. 3. 30-second TTL cache — opening, closing, and reopening the menu within 30s reuses prior status results and skips the IPC entirely. Cache survives across menu opens but is per-component instance (a global cache is a possible follow-up). 4. AbortController cancellation — closing the menu (or destroying the component) cancels in-flight checks so a slow portal can't write stale results into the next round. Solves the 'rapidly open/close the menu and watch dots flicker' problem. The actual IPC layer wasn't changed — the wins come purely from streaming, caching, and not lying to the user about portal state. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 58a2d50756dd