Fixed
- Dispatcharr web UI 504 / crash when zapping channels with a schedule configured — fixed at the deeper layer (follow-up to 1.26.1960020). The previous fix made scheduler re-arming a no-op, but its bookkeeping lived in module-level variables, which only survive plugin re-instantiation. On some installations Dispatcharr's plugin loader additionally re-imports the plugin module on nearly every streaming event (a reload loop in Dispatcharr itself — one plugin install/update can start it, and with more than one worker it never converges). Each re-import wiped the bookkeeping, so every channel zap silently started a NEW background scheduler thread and orphaned the old one — accumulating until the web workers starved and nginx returned 504, while streams kept playing. Scheduler state now lives outside the plugin module where the loader's reload cannot wipe it: re-arming after a re-import finds the live thread and does nothing, stopping works across re-imports, and a genuine plugin update or schedule/settings change still restarts the thread.
- A typo in Scheduled Times (e.g.
0330 0445— space instead of comma) no longer puts every request on the slow path — an unparseable schedule settles as "scheduler off". - Settings changes now reach an already-running schedule — changing e.g. the Channel Profile without touching the times restarts the scheduler with the fresh configuration (it used to keep firing with the old settings until a container restart).
- Clearing the schedule while a scheduled run is in flight no longer taxes later requests, and logs a distinct warning instead of a misleading "stopped".
If you saw the UI die during channel surfing on 1.26.1960020 with a schedule set: update to this version, or as an interim workaround clear the Scheduled Times field and restart the container once.
584 tests green, including a new regression suite that simulates Dispatcharr's module-reload behavior.