Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#12968 closed Bug Report - General (fixed)

"Find and record one showing of this title each day" broken since .28

Reported by: skd5aner@… Owned by: gigem
Priority: minor Milestone: 0.28.1
Component: MythTV - Scheduling Version: 0.28.0
Severity: medium Keywords:
Cc: Ticket locked: no

Description

In .27, recording rules were simplified, but it was stated that "find and record one showing of this title each day" would still be available in custom recording rules.

Since upgrading to .28, all of my "find and record one showing of this title each day" rules fails to honor the "find once a day" part. I can look the custom rule up in mythweb, and in fact see that it's still flagged to record only 1 a day. Also, in the frontend UI, I see no way to see "find and record one showing of this title each day" as an option on a custom recording rule.

This results in shows that air multiple times a day, even across multiple networks, to get recorded several times a day. SportsCenter? is a great example, although I have many other examples as well - mostly daily news or sports shows.

Change History (7)

comment:1 Changed 3 years ago by skd5aner@…

comment:2 Changed 3 years ago by Stuart Auchterlonie

Milestone: unknown0.28.1

comment:3 Changed 3 years ago by gigem

Status: newassigned

Matt, I only upgraded my production system to 0.28 last week and saw some find daily weirdness right away too. I didn't have time to look at it then and have been unable to reproduce it since. My first guess is the corrupt recording detection thinking an earlier showing is bad and causing another recording to take place. If you see the problem again, look at the duplicate column in the recorded table. Also, check to see if the recordid is in the oldfind table.

comment:4 Changed 3 years ago by gigem

I saw another instance of this last night. The evening showing was recorded and later deleted, but the overnight showing was then set to record. Matt, is that what your are seeing?

I had a chance to do a little debuggging this time. There was an entry in oldfind, which is supposed to prevent such situations. However, the entry in recordmatch for the overnight showing didn't account for it. There could be a race condition with creating the oldfind entry. Even so, the reschedule after the later deletion should have picked it up. That would seem to indicate the overnight showing wasn't being considered for update after the deletion. Now that I kind of know what I'm looking for, I'll try to keep an eye on when and where it goes wrong.

comment:5 Changed 3 years ago by David Engel <dengel@…>

Resolution: fixed
Status: assignedclosed

In 2afb621d248b0e5968ec79f149a7b0a535cf8a47/mythtv:

Fix issue with find recording rules.

The bindings for the query used to mark later showings baded on
findids were wrong. If an earlier recording was deleted, it could
result in later showings being recorded when they shouldn't have.

Fixes #12968

comment:6 Changed 3 years ago by David Engel <dengel@…>

In d5d1bce10fd6e7eecaa9076ac5c7e5e784da8bda/mythtv:

Fix issue with find recording rules.

The bindings for the query used to mark later showings baded on
findids were wrong. If an earlier recording was deleted, it could
result in later showings being recorded when they shouldn't have.

Refs #12968

(cherry picked from commit 2afb621d248b0e5968ec79f149a7b0a535cf8a47)

comment:7 Changed 3 years ago by David Engel <dengel@…>

In 6fb800d9c4866d25fefd082e0bd408bd0fd624c2/mythtv:

Fix issue with find recording rules.

The bindings for the query used to mark later showings baded on
findids were wrong. If an earlier recording was deleted, it could
result in later showings being recorded when they shouldn't have.

Refs #12968

(cherry picked from commit 2afb621d248b0e5968ec79f149a7b0a535cf8a47)

Note: See TracTickets for help on using tickets.