[mythtv-users] "Keep at most N episodes" fails to delete

[Dan Wilga]

On 6/28/12 5:28 PM, David Engel wrote:
> On Thu, Jun 28, 2012 at 04:40:27PM -0400, Dan Wilga wrote:
>> On 6/28/12 2:56 PM, David Engel wrote:
>>> On Thu, Jun 28, 2012 at 01:58:31PM -0400, Dan Wilga wrote:
>>>> On 6/27/12 9:54 PM, David Engel wrote:
>>>>> On Wed, Jun 27, 2012 at 04:25:16PM -0400, Dan Wilga wrote:
>>>>>> Since switching to 0.25 (-fixes), I've noticed that a recording rule
>>>>>> I had set up in 0.24 to only keep the last three episodes of the
>>>>>> nightly news isn't automatically deleting the older episodes
>>>>>> anymore. I've checked and re-checked the recording rule and can't
>>>>>> figure out the reason.
>>>>>>
>>>>>> It's set for "Keep at most 3 episodes" and "Delete oldest if this
>>>>>> would exceed the max episodes", yet I currently have 9 episodes and
>>>>>> have to keep manually deleting them.
>>>>>>
>>>>>> Is anyone successfully using this feature in 0.25?
>>>>> Do any of the oldrecorded entries for your recordings not have the
>>>>> duplicate flag set?  There is a debatable feature where damaged
>>>>> recordings or recordings that you explicitly set to allow re-recording
>>>>> don't count against the episode limit.  You can check the duplicate
>>>>> status by pressing ENTER in the Previously Recorded screen and seeing
>>>>> if you get the "Never record this episode" option.
>>>>>
>>>> I checked using a database query, and all of the recordings that
>>>> occurred do have duplicate=1:
>>>>
>>>>    SELECT * FROM oldrecorded WHERE title LIKE '%NewsHour%' AND
>>>> future=0 AND chanid=5571
>>>>
>>>> Where is the autoexpire query in the code? If there is some other
>>>> flag that is causing the issue, I might be able to figure it out,
>>>> once I know the full query.
>>> It's in AutoExpire::ExpireEpisodesOverMax().
>>>
>> OK, it actually turns out that the query is using recorded, not oldrecorded:
> Oh, yes, of course!  I apologize for initially sending you in the
> wrong direction.
>
>>    SELECT chanid, starttime, title, progstart, progend,  filesize,
>> duplicate  FROM recorded WHERE recordid = 1652 AND preserve = 0  AND
>> recgroup NOT IN ('LiveTV', 'Deleted')  ORDER BY starttime DESC;
>>
>> Your suspicion is correct that, for some reason "duplicate" is zero
>> for all of these recordings in "recorded". Here's a backend log
>> entry for one of them:
>>
>> I TVRecEvent tv_rec.cpp:812 (FinishedRecording) TVRec(3):
>> FinishedRecording(5571_2012-06-26T18:32:00) damaged
>> recq:<RecordingQuality overall_score="0.495833"
>> key="5571_2012-06-26T18:32:00" countinuity_error_count="0"
>> packet_count="22204915">#012    <Gap start="2012-06-26T18:30:00"
>> end="2012-06-26T18:32:01" duration="121" />#012</RecordingQuality>
>>
>> This is despite the fact that the recording seems to be fine to me.
>> (Since this is an OTA recording, perhaps there is bad data
>> somewhere, though.) What results in this condition? Is there any way
>> to keep it from being marked this way?
> The recording quality check is new in 0.25 and definitely needs work.
> For example, it doesn't do a good job accounting for start-early and
> end-late (and probably large pre/post-roll).
>
> In your case above, it's saying you have a 2 minute and 1 second gap
> that didn't get recorded.  Did your recording start late for some
> reason or did you manually stop it early?
I think you've hit on the problem. The program begins at 18:30:00, but I 
have it scheduled to start 2 minutes late, since there's always at least 
2 minutes of ads first.

Looking in the backend logs, this same non-error is reported every day 
for this recording. So it seems there is an additional bug having to do 
with starting a recording late (not just early), and this is the reason 
for my recordings not expiring.

Is there any way to turn off this feature, short of recompiling? If not, 
where can I find the code to excise?

-- 
Dan Wilga                                                        "Ook."