Mailing List Archive: MythTV: Users

"Keep at most N episodes" fails to delete

Index | Next | Previous | View Threaded

mythtv-users2 at dwilga-linux1

Jun 27, 2012, 1:25 PM

Post #1 of 12 (835 views)
Permalink

"Keep at most N episodes" fails to delete

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?

--
Dan Wilga "Ook."

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

newmank1 at asme

Jun 27, 2012, 2:34 PM

Post #2 of 12 (821 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

On Wed, Jun 27, 2012 at 1:25 PM, Dan Wilga
<mythtv-users2 [at] dwilga-linux1> 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?
>
> --
> Dan Wilga "Ook."

I've been experiencing strange scheduler problems with pre-0.25
recording rules, too. Mine mostly have to do with failing to schedule
a recording for no identifiable reason. I had a regular "Any time on
any channel" rule for Futurama, and I had also added a Title search to
catch the occasional movie. Myth properly recorded last week's airing,
but tonight's was not scheduled and I couldn't tell why. I added a new
"Any time on any channel" and it became scheduled. I compared the new
record rule to the old rule in the database but I couldn't spot any
key difference. I then removed all the old rules and created a new
Title search rule and everything is scheduled again correctly. *shrug*

TL;DR: Try deleting and re-creating the rule.

Karl
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

dbadia at gmail

Jun 27, 2012, 4:18 PM

Post #3 of 12 (817 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

On Wed, Jun 27, 2012 at 4:25 PM, Dan Wilga <
mythtv-users2 [at] dwilga-linux1> 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?
>
> --
> Dan Wilga "Ook."
>
> ______________________________**_________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>

It's working fine for me on .25. I had a couple of existing rules like
this in .24 for daily news programs. It's still working as intended,
deleting the old episodes and recording the new.

Dave

david at istwok

Jun 27, 2012, 6:54 PM

Post #4 of 12 (814 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv-users2 at dwilga-linux1

Jun 28, 2012, 10:58 AM

Post #5 of 12 (811 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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.

--
Dan Wilga "Ook."

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

david at istwok

Jun 28, 2012, 11:56 AM

Post #6 of 12 (804 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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().

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv-users2 at dwilga-linux1

Jun 28, 2012, 1:40 PM

Post #7 of 12 (805 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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:

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?

--
Dan Wilga "Ook."

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

david at istwok

Jun 28, 2012, 2:28 PM

Post #8 of 12 (807 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv-users2 at dwilga-linux1

Jun 29, 2012, 6:47 AM

Post #9 of 12 (795 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

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."

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

david at istwok

Jun 29, 2012, 7:52 AM

Post #10 of 12 (801 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

On Fri, Jun 29, 2012 at 09:47:30AM -0400, Dan Wilga wrote:
> On 6/28/12 5:28 PM, David Engel wrote:
> >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?

There is a hidden setting named MinimumRecordingQuality that controls
whether or not a recording is considered to be damaged. It's a
percentage and recordings with a score less than this value are
considered damaged. Setting the value to 0 effectively disables the
recording quality check altogether.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

danielk at cuymedia

Jun 30, 2012, 2:36 PM

Post #11 of 12 (773 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

Dan,

I've created a ticket for this issue here:
http://code.mythtv.org/trac/ticket/10872

The attached patch should fix this for your case, but I don't think
it's actually the right solution since it doesn't discriminate between
recordings that started late because of say a system restart vs
recordings with an intentional late start.

-- Daniel

Attachments:

rq.patch (1.02 KB)

mythtv-users2 at dwilga-linux1

Jul 2, 2012, 6:26 AM

Post #12 of 12 (745 views)
Permalink

Re: "Keep at most N episodes" fails to delete [In reply to]

On 6/30/12 5:36 PM, danielk wrote:
> I've created a ticket for this issue here:
> http://code.mythtv.org/trac/ticket/10872
>
> The attached patch should fix this for your case, but I don't think
> it's actually the right solution since it doesn't discriminate between
> recordings that started late because of say a system restart vs
> recordings with an intentional late start.
Thanks for taking the time to work on this, Daniel. I'll give the patch
a try (and remove the hidden setting mentioned previously.)

--
Dan Wilga "Ook."

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads