[mythtv] auto expire problem with "max episodes" option

[Michael T. Dean]

On 10/09/2014 01:07 PM, George Nassas wrote:
> On Oct 9, 2014, at 7:16 AM, Michael T. Dean wrote:
>
>> Please post a mythbackend log running with -v file showing the autoexpire run.  You should see information such as the total number of episodes it's identifying for each recording rule with max episodes set.  My best guess is that the "extra" episodes are from rules that no longer exist (i.e. recid has changed on those rules) or exist in the Live TV or Deleted recording group or something like that.
> Good guesses but wrong. They're all recent recordings, I don't use live TV, all are in the "Default" rec group, etc. The oldest rule has been around for six years dutifully trimming excess recordings until last April. Originally I wrote June but I went back and looked and the oldest unexpired show is from April 21. The newest rule is for Seth Meyers' show which I think started in January. There's an expire log at http://pastebin.com/ZCN7YKvc and at the bottom of the file a select against the most problematic recording rule, 1253, showing what's in the database for it.
>
> While investigating before posting I manually executed the per-rule select of the autoexpire method and traced through the logic. It all looked good except for the part about the "duplicate" column...
>
>> "duplicate" doesn't mean it's a duplicate.  The duplicate column only identifies an episode as one that /should/ be used in duplicate matching (i.e. one that MythTV should acknowledge as having been recorded)--it says nothing at all about whether or not it's a duplicate episode.
> That's good information and too bad about the regrettable column name. Could it be that the policy for unidentified/generic episodes has been changed and they now take 0 for duplicate where they used to have 1? I don't remember any commits going by like that but it doesn't mean it didn't happen. Something to investigate.
>
> The 1253 rule is for a current affairs show that rarely has episode information, I don't think they freeze their lineup until a few hours before airtime. I have a post-recording job that scrapes their website and updates the subtitle, description, and airdate&  it wouldn't be much for me to tweak the "duplicate" column at the same time.
>
> Assuming this analysis is correct I see how to fix my problem but it remains that there's a subtle bug or misbehaviour in myth that ought to be dealt with. Perhaps by addiing a "generic" check in that if (duplicate) test?

The question is why your generics are being marked with duplicate = 0.  
TTBOMK, they shouldn't be (and I know they haven't been in the past).  I 
don't think anyone has added any code to change it such that generics 
get duplicate = 0 set--since duplicate is still explicitly ignored for 
generics (see scheduler.cpp and the "generic = 0" sections).  If someone 
did so as some sort of performance enhancement, it was an invalid 
approach since it will have other repercussions (as you've noticed).

Perhaps these are getting duplicate = 0 because the recording quality 
code determined them to be damaged (and it's unrelated to whether it's a 
generic episode)?  You do seem to have quite a few with subtitles (I'm 
assuming they're not generic, though it's a guess since I don't have 
program IDs) that are also marked duplicate = 0.  You could see more 
info from TVRec::FinishedRecording() (which calls 
RecordingInfo::FinishedRecording(bool allowReRecord) , which does set 
duplicate = 0 if allowReRecord is true) if you run the backend with -v 
record (though even with general logging, you should see messages if the 
recordings are damaged) but you'd have to actually catch a failure.

Mike