[mythtv] [mythtv-commits] Ticket #3196: Autoexpire and backend fail to heed maxnewest = 0, deletes old programs that shouldn't and records new ones

Chris Pinkham cpinkham at bc2va.org
Thu Mar 15 03:32:27 UTC 2007


* On Wed Mar 14, 2007 at 04:32:21PM -0500, subbyz at kinison.puremagic.com wrote:
> >We don't check maxnewest here because the expirer isn't in charge of
> >what gets recorded, it just deletes the oldest (or whatever the expire

> I'd agree that the expirer isn't in charge of what gets recorded, but I 
> disagree that the maxnewest flag only affects the scheduler.

In the maxepisodes case, the expirer doesn't care about anything but
how many episodes you have recorded for that recordid and which ones
are over the limit.  The newest 'maxepisodes' episodes with their
recorded.preserve value set to 0 get to stay and anythong over the
max with preserve == 0 gets (has) to go. 
 
> For a logical implementation of the maxnewest functionality, the maxnewest 
> flag affects both the scheduler and the expiration, so the test for if it 
> is set needs to be part of the expiration code as well.  If the maxnewest 
> flag /only/ controls the scheduler, then there needs to be some other 
> mechanism for controlling if the shows are expired, and right now there 
> doesn't appear to be.

The expirer shouldn't have to care.  If the scheduler is doing its
job then the expirer knows that it just has to delete the maxepisodes+1
show in starttime descending order.  If the scheduler does its job and
doesn't record any new episodes then the expirer won't have to delete
them.  When the scheduler does record a new episode, it means that
maxnewest is turned on, and the expirer then deletes the oldest if the
count is over the maxepisodes limit.

> Here's an example where not checking the maxnewest flag in the expiration 
> code results in undesired behavior:
> 
> Setup a rule to record a limit of 10 shows, with maxnewest = 0 and 
> autoexpire = 0.  After 10 shows are recorded, no more are scheduled.  Then 
> you go back in and modify the rule to say you only want it to record 5 
> shows for that rule.

If you do that, then expect your 5 oldest episodes to be expired, unless
you turned on their 'preserve' flag.  The expirer does what it is
supposed to do, keep only 5 episodes of the show around.

> If as you argue, the flag and limit only affect the 
> scheduler and not the expiration, then I would not expect shows that had 
> already been recorded to be deleted out from under me, especially when I 
> may have specifically upped the limit temporarily to get some extra shows.  

If you want the limit bumped up so you can get some extra shows then you
better turn on the preserve flag or else they'll disappear when you
bump the limit back down.  The AutoExpirer is working as intended (and
as I wrote it) here.

> But if the expiration code doesn't heed the maxnewest flag, then it will go 
> ahead and delete the 5 extra shows, which I would consider incorrect as 
> well as very undesireable.

Then you should be using the preserve flag, that is what it is for.
>
> Either the expirer also needs to heed the maxnewest flag on the recording 
> rule, or it needs to REALLY honor the autoexpire = 0 setting on the 
> recorded programs, which it currently does not.  And doing it with the 
> autoexpire flag is actually less logical and has some other side issues as 

The maxepisodes overrides the autoexpire flag.  You don't have to turn on
autoexpire on a recording that has maxepisodes set.  Maxepisodes takes
precedence and everything is working as intended in the expirer.  The
only issue here is the scheduler.

> well.  With the current schema and behavior, I think heeding the maxnewest 
> flag in the expirer is the best solution.

Using the preserve flag is the best solution for your scenario.  Or don't
bump the maxepisodes back down until you only want 5 episodes to be
kept around.

--
Chris


More information about the mythtv-dev mailing list