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

David Engel david at istwok.net
Thu Jun 28 21:28:35 UTC 2012


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?

David
-- 
David Engel
david at istwok.net


More information about the mythtv-users mailing list