[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