Saving/previewing Time Slot changes freezes all live channels simultaneously, and current Max Lateness/Pad Times handling doesn't recover cleanly from it

[DarkManX16]

Confirmed behavior:

Clicking "Save" after editing a channel's Flex settings in the Time Slot Editor causes a delay/buffering on all 3 currently-live channels at once — not just the channel being edited. This delay leads directly to schedule drift (actual playback falling behind what the Guide/Time Slot Editor says should be airing). A full Tunarr restart clears the drift, but it recurs the next time you click save.

Why "all channels at once" matters:

Since editing one channel's schedule pauses every channel simultaneously, this points to the server's main thread blocking on something synchronous during the save, rather than per-channel schedule state being corrupted individually.

How this becomes visible drift:

The stall itself costs real playback time. Whether that shows up as lasting schedule drift depends on each channel's lateness handling:

• Max Lateness (set on my Cartoon Cartoons Network and That's So Disney channels) governs whether a program that's now running behind gets to keep playing or gets cut back to schedule — but doesn't appear to reconcile the underlying time debt from the stall itself.
• Pad Times (set on all 3 channels) inserts Flex to align the next slot to a clean boundary — but if it's calculating against an already-drifted wall-clock position, it's padding around a wrong baseline rather than correcting it.

Result: drift builds up incrementally with each Flex edit rather than getting corrected, and only a full Tunarr restart clears it (forces a fresh resync to true wall-clock time).

Tested and ruled out:

Reduced "Days to Precalculate" from 365 to a much smaller window — delay still occurs. So, the precalculation window size isn't the driver; whatever's blocking happens regardless of how much schedule is actually being recomputed.

Suggested direction:

Since the delay is present even at low precalculation depth, this smells like something in the save path that's synchronous by nature (e.g., a blocking write, a full schedule re-validation, or a live-session notification step) rather than scaling with computation size. Worth checking whether the slot-save handler does anything on the main thread that could be made async or offloaded, since it's currently able to stall every live channel from a single-channel edit.

Suggested fixes:

1. Decouple "Preview Programming" from live session state entirely. A preview is conceptually read-only — it's generating something for the browser to display, not something that should ever need to touch whatever the live streaming session is actively reading from. If clicking Preview pauses live channels, that strongly suggests the preview computation is sharing or invalidating the same internal schedule object the live session depends on. This feels like the single highest-value, lowest-risk fix: give Preview its own scratch/read-only computation path that never intersects with anything a live channel touches. If this alone stops the preview-triggered stall, it's a strong signal the Save-triggered stall shares the same root cause and can be fixed the same way.
2. Scope schedule invalidation to the edited channel only. Since editing one channel currently pauses all three, something in the save path is likely broadcasting a global "schedule changed" signal rather than one scoped to the specific channel ID being edited. Worth checking whether the live-session reconciliation step filters by channel before acting, or just reacts to any schedule-changed event regardless of which channel it came from.
3. Move the actual recalculation off the main thread, e.g. via Node's worker_threads. Since ruling out precalculation depth as the cause, the stall is more likely a synchronous chunk of work blocking the single event loop rather than the computation being inherently slow. If it has to run inline for now, even yielding periodically (setImmediate/await between batches) so segment-serving requests can interleave would likely shrink the visible pause without needing a full architecture change.
4. Explicitly resync live session position to wall-clock time immediately after any save-triggered stall completes — not just on a full app restart. Right now, a restart is the only thing that forces the live cursor to reconcile with actual current time; making that same reconciliation happen automatically right after any interruption (a save, a stall, a crash recovery) would prevent small stalls from silently accumulating into visible drift in the first place, independent of whatever fix: delineate overflow and lateness in slot editors #1965 changes about Max Lateness/overflow semantics themselves.

(suggestion for the dev to verify against the actual code, not a confirmed fact)