[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