[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 18:02:51 UTC 2007


On Thu, 15 Mar 2007, Chris Pinkham wrote:

> I'm insisting because that's the way it is.  The scheduler is in charge
> of whether to record new episodes or not and the expirer is in charge
> of keeping X maxepisodes around.  It's as simple as that.

I understand that is the way it is and the way it is designed.  You appear 
not to think so, but I consider the way it is to be a bug, and would like to 
see it fixed, (or if you prefer, enhanced so it can do what I want).

We seem to be having a conflict of expectations.  You expect the maxnewest 
flag to only be a scheduler setting and don't care if that ends up causing 
the expiration code to delete shows.

But my expectation is that I don't expect shows to ever be automatically 
deleted when I've done just about everything I can settings-wise to ensure 
that they are not.  I just don't want the scheduler to record new ones.

Your way (as designed and currently implemented) is a fine way for it to 
operate, PROVIDED that there is some other reasonable and automatic way to 
keep the autoexpire code from deleting shows for a particular recording, NO 
MATTER WHAT.  But there doesn't appear to be.  Your suggestion of manually 
setting the preserve flag on every recording is neither reasonable nor 
automatic.

Deleting shows is a permanent and unrecoverable operation.  Maybe my way 
means the system retains a few extra shows in some circumstances, but they 
can always be deleted later.  With your way they are gone and can't be 
recovered.  I think it's wiser to err on the safe side.

> The scheduler
> won't record any new episodes if we are at the max _unless_ maxnewest
> is turned ON because then it knows that the expirer will handle deleting
> the oldest one.  The expirer's _only_ job is to keep us from exceeding
> maxepisodes.

I disagree, but that's probably because of how you worded it.  It's also the 
scheduler's job to keep us from exceeding max episodes by not recording new 
ones, but that says nothing about what to do if we've already exceeded the 
limit.

> I added the maxepisodes and maxnewest feature over 3 years ago and you're
> the first person that I know of that hasn't been able to understand
> that max means max.  If you set the max to 5, you can expect only 5
> episodes at most to be on the Watch Recordings screen next time you
> look at that program, unless you have preserved episodes via the popup
> menu on that same screen.

I think I understand fine, you just don't seem to be arguing your point very 
well.  You just said that max doesn't really mean max in the case where the 
preserve setting has been set on one or more episodes.  So it's obviously 
not an absolute rule as you tried to state the sentence before.  Since it's 
already a relative rule, what's the harm in changing the code to preserve 
shows that have already been recorded even if they exceed the limit? 
Especially when the help for that setting in the rule scheduling 
specifically says that it only affects new recordings, not expiration of old 
ones.

> Read the help text for the maxnewest setting:
>
> 	"Delete oldest if this would exceed the max episodes"  and
> 	"Don't record if this would exceed the max episodes"

Exactly.  You've made my point for me.  "Don't record if this would exceed 
the max episodes" says the scheduler will not record new shows if I'm 
already at or past the limit.  It does NOT say in any way that if I already 
have more shows than what is currently is set, that the old ones will be 
deleted.

> The root of the problem is that you're manufacturing invalid cases because
> you don't know enough about Myth to understand how to use it.  The preserve
> field was added because someone like you came along and said "I want to
> keep an episode and I don't want it to count against my max."

No need to get defensive.  Just because YOU don't use it the way I want to 
doesn't mean I'm "manufacturing invalid cases".  My examples are reasonable, 
and would have the problems I've illustrated.  I'm sure I don't know as much 
about myth as you do, but I haven't seen you dispute that right now it can't 
do what I want it to, even though it is safer to be done that way, and 
EXTREMELY trivial to fix.

>> 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.
>
> You don't.  If you wanted it set automatically then why not bump up the
> maxepisodes count?  You're not making sense.

I think I'm making plenty of sense.  I may set maxepisodes lower because I 
don't want new shows to be recorded.  But that doesn't necessarily mean that 
I want old already recorded shows to be deleted.  That's an expiration 
setting, and I've just set (in the setting immediately before that) for 
shows not to autoexpire.

> Automatically setting the
> preserve flag would negate the effect of turning on maxepisodes because
> nothing would be allowed to delete if it was over the max.  You may as well
> turn off maxepisodes and just manually delete things when you've watched
> them.

Your statement is completely untrue for the case where maxnewest is false. 
Setting maxepsiodes also makes the scheduler not record new shows if they 
would exceed the limit, which is the behavior I want.  I just also want the 
expirer not to delete them even if they are over the limit.  If as you 
suggest I just turned off the maxepisodes limit, then the scheduler would 
just keep on recording new episodes, which is definitely NOT desired.

> You just have to look for it.  Under the INFO popup menu on the Watch
> Recordings screen, there is a "Storage Options" submenu.

Ahh, thanks.  I doubt I'll use it as a manual setting is too much trouble, 
but nice to know about.

To avoid the appearance that I intend to go on "beating a dead horse", I'll 
refrain from responding to several additional points from your reply, as 
I've pretty much covered everything central to the issue.

> --
> Chris (who doesn't plan on commenting on this anymore and doesn't plan on
>       changing existing functionality other than fixing the scheduler bug)

Subbyz (who is sorry you've decided to make this confrontational rather than 
constructive, and appear to suffer from the "not-invented-here" syndrome of 
disregarding suggestions that would help improve the operation and 
flexibility).


More information about the mythtv-dev mailing list