Scheduler::UpdateManuals(): prevent scheduling recordings before the given start date

[ulmus-scott]

and rewrite the confusing code that calculated the start times.

I thought about adding something to prevent scheduling recordings in the past, but this function doesn’t have enough information to determine that.

if (MythDate::current().toLocalTime().time() > starttime) { offset++; }
The above code would prevent scheduling recordings that should have already started. However, the end time may still be in the future, so it should be scheduled in that case. Unfortunately, the startdate, starttime, enddate, and endtime values do not account for starting/ending the recording early/late (8 hours in either direction from the start and end), so this cannot be determined from the information the function has.

Therefore, this function will continue to schedule recordings that may be entirely in the past.

---

This is a modified cherry-pick from #643 since it is independent of the main reason of that PR.

Checklist

• contribution does not duplicate one of our existing pull requests
• contribution is in a branch rebased against master
• code compiles successfully without errors
• code follows the MythTV Coding Standards
• documentation added/updated/removed where necessary
• commits are logically organised and have good commit messages

[ulmus-scott]

I think an additional RecordingType that allows recording on either weekends or weekdays may be useful and make daily actually be all days:

diff --git a/mythtv/programs/mythbackend/scheduler.cpp b/mythtv/programs/mythbackend/scheduler.cpp
index 69cf223c52..bb3b2c19c9 100644
--- a/mythtv/programs/mythbackend/scheduler.cpp
+++ b/mythtv/programs/mythbackend/scheduler.cpp
@@ -3767,7 +3767,14 @@ void Scheduler::UpdateManuals(uint recordid)
     case kDailyRecord:
         for (int i = 0; i < daysInWeek * weeksToSchedule; i++)
         {
-            if (startDate.dayOfWeek() < 6 && startDate.addDays(offset + i).dayOfWeek() >= 6)
+            startList.push_back(QDateTime(startDate.addDays(offset + i), startTime, Qt::LocalTime).toUTC());
+        }
+        break;
+    case kWeekdayWeekendRecord:
+        for (int i = 0; i < daysInWeek * weeksToSchedule; i++)
+        {
+            if ((startDate.dayOfWeek() <  6 && startDate.addDays(offset + i).dayOfWeek() >= 6) ||
+                (startDate.dayOfWeek() >= 6 && startDate.addDays(offset + i).dayOfWeek() <  6))
             {
                 continue;
             }

but I'm not sure what changes would be required elsewhere.

[bennettpeter]

David Engel should review this as the expert on sheduler.

[gigem]

While the existing code might not be the prettiest, it works as intended and has known and consistent behavior. In addition, if any extensive work is going to be done on recording rules, I'd rather see it put into using a more expressive and extensible schema, perhaps in JSON.

Full disclosure, I have a very unfinished enhancement to allow specifying a recording group to any rule. If I finish it before anything significant changes, I'll likely break my own rule and allow it. 😀

[ulmus-scott]

This also prevents the scheduler from scheduling recordings before the specified start date.

For example: today is 2025-06-01, if I set up a daily recording starting on 06-05, it will also schedule recordings for 06-02 through 06-04. I consider that a bug, since it has scheduled recordings before the start date.

This also occurs with weekly recordings.

[gigem]

I know that and it's inconsistent with all other recurring rule types which all start immediately. Starting on such and such date (and the complementary ending on such and such date) is an entirely new feature that has applicability to other rule types. As such, I'd rather see any effort on it put into the more robust and complete solution I outlined (albeit briefly).

[ulmus-scott]

We only use manual recording rules, so I don't know how any other rule behaves. It makes sense to me that manual recordings could behave differently.

I agree being able to set a start and end date for any rule would be nice; however, the manual rules already specify a start date and it doesn't work right, so I don't see why it couldn't be fixed while waiting on this potential extensive rework.