Opened 18 years ago
Closed 18 years ago
#643 closed defect (fixed)
Program matching multiple recording schedules behaves unexpectantly
Reported by: | Owned by: | gigem | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
If you create multiple recording schedules, the behavior is unexpected (for this user, at least).
Consider two recording schedules: Schedule NEWEPISODES that "record new episodes only" with priority +1 Schedule REPEATS that records all repeat episodes of show A with priority -1 (REPEATS is programmed as a "Custom Record", FIRSTRUNS was added first, lower recordid)
Episode A, a new episode, matches against NEWEPISODES and is scheduled with priority +1.
Episode B, a repeat, matches against NEWEPISODES, but is then discarded as a repeat. It is not considered as a match against REPEATS.
This appears to be a problem in PruneRedundants?. Patch forthcoming.
Attachments (2)
Change History (5)
Changed 18 years ago by
Attachment: | scheduler-double.patch added |
---|
comment:1 Changed 18 years ago by
It was actually PruneOverlaps? that was causing the problems. It resolves exact overlaps (same bat time, same bat channel) by looking at RecTypeOverlap?. The proposed patch also looks at whether or not programs is marked rsInactive or rsRepeat.
Changed 18 years ago by
Attachment: | scheduler-double-alt.patch added |
---|
This better maintains original intent of the code (more-specific RecordingTypes? win over less-specific)
comment:2 Changed 18 years ago by
Milestone: | → unknown |
---|---|
Owner: | changed from Isaac Richards to gigem |
Version: | → head |
Reassigned to David Engel (gigem), see GoToDev.
comment:3 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
In cases where two recording rules match the same showing, one of them needs to take precedence. An rsRepeat or rsInactive will not be considered for recording so we penalize these to force them to yield to a rule that may record. Otherwise, more specific record type beats less specific.
The patch suggests priority as a factor but neither gigem or I are comfortable with this. The controlling rule could flip-flop when changing a priority on a different showing for a different reason. Also, it is unknown if there would mysterious behavior due to the total priority calculations (input preference, channel priority) that may lead to unexpected results. Therefore, this will not go in unless someone can make a very compelling argument for it.
Proposed patch