[mythtv] [mythtv-commits] Ticket #3196: Autoexpire and backend fail to heed maxnewest = 0, deletes old programs that shouldn't and records new ones
subbyz at kinison.puremagic.com
subbyz at kinison.puremagic.com
Wed Mar 14 21:32:21 UTC 2007
>* On Mon Mar 12, 2007 at 09:23:24PM -0000, MythTV wrote:
>
>> Comment(by subbyz):
>
>> After looking through the 0.20 source, it appears that
>> AutoExpire::ExpireEpisodesOverMax is not testing maxnewest > 0 in it's
>> checks.
>> query.prepare("SELECT recordid, maxepisodes, title "
>> "FROM record WHERE maxepisodes > 0 "
>> "ORDER BY recordid ASC, maxepisodes DESC");
>
> 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
> sort order is set to). The scheduler is the one that is in charge of
> whether we record new episodes. There is a bug in the scheduler's
> maxepisodes logic, it is not checking the recordid of the rule against
> the recordid of the existing programs. maxepisodes used to look at
> the program title, now it looks at the recordid, but the scheduler was
> never changed to take this into account. I looked at this when you
> submitted your ticket and verified, but didn't make any comments about
> it, I just moved it into my view because I know what the fix is.
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.
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.
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 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. 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.
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 well. With
the current schema and behavior, I think heeding the maxnewest flag in the
expirer is the best solution.
subbyz
More information about the mythtv-dev
mailing list