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

Subbyz subbyz at kinison.puremagic.com
Thu Mar 15 06:21:08 UTC 2007


On Wed, 14 Mar 2007, Chris Pinkham wrote:

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

I'm not sure why you are insisting that the maxnewest flag is only for use 
by the scheduler.  The maxepisodes and maxnewest settings are logically 
closely related in how shows are dealt with after being recorded.

With that being the case, it seems to be a little inconsistent if you are 
saying that the maxnewest flag is (and should be) solely a scheduler 
setting, while it's ok for the maxepisodes setting to be used by both the 
scheduler and the expirer.  If the maxepisodes setting is used by both, why 
can't they both use the maxnewest too?

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

And that is my point, and seems to be root of the problem.  I wouldn't 
expect it to delete shows that I've already recorded, when they are set to 
not autoexpire AND I don't have maxnewest set.  I agree the max limit should 
keep more shows from being recorded, but it should NOT affect deletion of 
episodes that I may have specifically increased the limit in order to get. 
Once they are on disk, and I have autoexpire on them set to 0, then I do not 
expect them to disappear from under me for any reason unless absolutely 
necessary (like running out of disk space).

> 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.
>...
> Then you should be using the preserve flag, that is what it is for.

Ok then, how does one go about getting the backend to automatically set the 
preserve flag on all episodes recorded under a certain rule?  I may have 
missed it, but I don't see a setting that appears to do that.

Come to think of it, I haven't even seen a way to set the preserve flag 
manually for an individual recording.  Is that a new flag that isn't fully 
supported yet?  Even if there is, I certainly hope that you're not 
suggesting that having to go and manually set a flag on a bunch of 
recordings is an acceptable way to get the desired behavior of having it not 
delete existing recordings.

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

I realize that maxepisodes overrides the autoexpire flag, and that it is 
behaving as it was designed.  But I think it should be changed so that it 
only does so when the maxnewest flag is true.  Otherwise, the maxepisodes 
should only affect the scheduler, and not the expirer.

Another big reason it is a problem (in addition to being more work for the 
user) is because it exposes a race condition to the user.

Suppose I had done as my previous example and bumped up the recordings 
temporarily for a long weekend or something like that.  After the backend 
has gotten a few extra shows, I want to bump it back down, but wait, I can't 
do that yet because if I do the expirer will delete programs that I want and 
even may be in the middle of watching.

In my specific case, the recording rule is getting all programs with a genre 
of "Documentary".  Now, with Discovery channel and several other educational 
channels, one program or another of type "Documentary" is on pretty much at 
all hours of the day.  So, even though it is a hassle, since I don't want 
programs to be deleted out from under me, I try to follow your suggestion of 
not reducing the limit until I've cleared out some programs to get it below 
the limit.

So, after I've watched and deleted a program, now I immediately have to go 
and change the recording rule to decrease it's maxlimit by one, or the 
backend will start recording another show of "Documentary" at the next hour 
or half hour.  If I'm not quick enough, the backend may already have started 
a recording, and when I do go get the setting changed, now the expirer will 
delete an older program I haven't yet finished watching, which is exactly 
what I was trying to avoid.  So I've done a lot more work, and ended up 
being hit or miss on wether I worked around the problem that is currently 
inherent in the design.

Making the user do more work just to get around inconsistencies and race 
conditions in the code just seems like a bad idea to me.  Especially when 
the fix is so simple and logical.

subbyz


More information about the mythtv-dev mailing list