[mythtv] [PATCH] Control duplicates by channel ID

[David Shay]

On 8/7/07, David Shay <david at shay.net> wrote:
> On 8/7/07, David Engel <david at istwok.net> wrote:
> > On Tue, Aug 07, 2007 at 01:56:18PM -0500, David Shay wrote:
> > > > Yes, the AddHistory should also be qualified by
> > > >
> > > >   nextRecording->recstartts <= schedTime
> > >
> > > After some more thought, I wondered if maybe the check should be a
> > > call to IsSameTimeslot instead?  I'll try some things out tonight.
> >
> > I don't follow.  In PruneRedundants(), any call to AddHistory() must
> > be qualified by the current time in order to match how it would have
> > been called in RunScheduler().  IOW, anything in that might happen in
> > the future is still conjecture at that point.  Only after the
> > scheduler would have acted on something, does it become a mater or
> > record.
> >
>
> Sorry, I wasn't clear.  I meant not JUST the check for <= schedtime
> but ALSO a check to IsSameTimeslot so that we were only adding the
> "precise" "potentially unnecessarily duplicate" entries to
> oldrecorded.
>
Well, never mind about that.  That check isn't needed.  But, this
doesn't completely solve the problem.  Here was a sample case:

1 record rule, any channel, new duplicate rule set to off (normal,
existing behavior)
show matches 3 showings, 2 on one callsign, 1 on a different callsign.
Scheduler detects 1 of the showing on the same callsign as will
record, the other as other showing.  The one on the different callsign
is EarlierShowing.  So far, so good.
Recording starts.  Only 2 entries get added to oldrecorded, the one
for the chanid with the callsign it is really being recorded on
(status -2), and the one with the chanid and the different callsign
(status 4).  It should have added the other chanid, but didn't.  It
must not have made it through to PruneRedundants at that point, I
guess.  (I'll need to add more debug stuff to check why not).

Recording ends.  The additional entry gets added to oldrecorded, but
with a status of -3 for recorded, when it should have been 13 for
othershowing.  The one that was really recorded also gets set to -3.
I've traced this back, I think, to the fact that when a recording ends
it updates it's status via a call to UpdateRecStatus using a pointer
to *pginfo structure, which then uses IsSameProgramTimeSlot.

Initially, I had further qualified the call here to do the check if
dupchanid was set, then to also check on matching channel ID's.  In
this case, the new dupchanid was not in effect, so it just went about
it's merry way iterating through, found 2 matches for the same
callsign via IsSameProgramTimeSlot and updated them both with the
recorded status, incorrectly.

I'm not 100% certain of this, but if the goal is to always add
oldrecorded entries for the past/current stuff, maybe UpdateRecStatus
should just ALWAYS check on a chanid match, just like the join in
FromProgram will now always join on chanid.

Still have to solve the problem of why the initial same callsign/not
recording channel ID didn't get to oldrecorded first, but if it HAD,
then the above logic would work.

Thoughts?