Opened 18 years ago

Closed 18 years ago

#643 closed defect (fixed)

Program matching multiple recording schedules behaves unexpectantly

Reported by: mythtv@… 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)

scheduler-double.patch (726 bytes) - added by mythtv@… 18 years ago.
Proposed patch
scheduler-double-alt.patch (1.3 KB) - added by mythtv@… 18 years ago.
This better maintains original intent of the code (more-specific RecordingTypes? win over less-specific)

Download all attachments as: .zip

Change History (5)

Changed 18 years ago by mythtv@…

Attachment: scheduler-double.patch added

Proposed patch

comment:1 Changed 18 years ago by mythtv@…

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 mythtv@…

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 danielk

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 bjm

Resolution: fixed
Status: newclosed

(In [8191]) Closes #643

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.

Note: See TracTickets for help on using tickets.