[mythtv] [PATCH] Control duplicates by channel ID

David Shay david at shay.net
Wed Aug 8 19:45:03 UTC 2007


On 8/7/07, David Shay <david at shay.net> wrote:
> 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).

OK, determined the problem to be that the scheduler runs in advance of
the program starting, so the check on recstartts <= schedtime is
false, so the record doesn't get added.  The scheduler doesn't re-run
again until after the program has ended rerecording, which after the
statuses have already been screwed up by the call as below.  Not sure
what the right check here is, but it's not against schedtime I don't
think.


>
> 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?
>


More information about the mythtv-dev mailing list