Update: found the actual cause, and it isn't UTC.
The Monitor schedule stores days as System.DayOfWeek values combined as bit flags, but
DayOfWeek isn't a flags enum (Sunday=0, Monday=1 ... Saturday=6). The checkboxes combine
days with |= and test them with &, and the recording check uses
HasFlag(DateTime.Now.DayOfWeek), so days overlap:
- Wednesday (3) = Monday | Tuesday
- Friday (5) = Monday | Thursday
- Saturday (6) = Tuesday | Thursday
- Sunday (0) can't be stored at all
That explains everything in my original post:
- Ticking Wednesday re-opens as Mon+Tue+Wed, Friday as Mon+Thu+Fri, Saturday as Tue+Thu+Sat.
- Sunday always shows ticked, and unticking it does nothing.
- Sunday only gives "you must select a day", because its value is 0.
- Unticking one day unticks others that share its bits.
- At runtime, every scheduled monitor is also active on Sundays, and Wed/Fri/Sat schedules
run on two extra days.
Fix: use a [Flags] enum with one bit per day (Sunday=1, Monday=2, Tuesday=4, Wednesday=8,
Thursday=16, Friday=32, Saturday=64, All=127), test today with
(mask & (1 << (int)DateTime.Now.DayOfWeek)) != 0, and convert existing saved values
(currently 7 = every day).
Ken Kopin
Version: 2026.7.17.35
OS/Timezone: Windows, Eastern Time (UTC−4, currently EDT)
Description:
The Schedule tab on Monitor entries has several related issues with day selection:
Selecting a single day and saving sometimes returns a "you must select a day" error, as if the selection isn't being read correctly.
When a single day does save, returning to the monitor often shows an additional adjacent day has been added.
Unticking a day sometimes unticks other unrelated days simultaneously.
If you remove the phantom extra day added in #2, you're back to the error in #1.
The net result is that it's impossible to reliably constrain a monitor to a single day.
Suspected cause: The day selection logic may be storing or validating selections in UTC rather than local time, causing off-by-one day errors depending on the user's UTC offset. The adjacent-day drift is not consistent (sometimes before, sometimes after the selected day), which could indicate the offset is being applied in different directions at different points in the save/load cycle.
Why this matters: The Monitor is preferable to the Scheduler for live streams because it starts recording when the stream actually goes live and stops when it ends, rather than requiring a fixed duration. The Schedule tab on the Monitor is the only way to avoid polling every 30 seconds around the clock for a stream that only airs on a specific day.