[mythtv] [PATCH] Control duplicates by channel ID

David Shay david at shay.net
Tue Aug 7 02:54:08 UTC 2007

On 8/6/07, David Engel <david at istwok.net> wrote:
> On Mon, Aug 06, 2007 at 06:05:16AM -0500, David Shay wrote:
> > >I'm not sure
> > > PL::FromProgram could do this since the recordid wouldn't be available
> > > until after the join.
> >
> > Right.  However, Bruce earlier added code to insert the additional
> > check after the query to verify on dupchanid and check the chanid's.
> > That still doesn't guarantee the right status for programs in the
> > past, though.  What about "hardcoding" a forced join on chanid, just
> > for FromProgram?
> That won't work without other changes.  In PruneRedundants, PIs for
> some chanids can get removed without ever having a corresponding
> oldrecorded entry.  Consequently, if the FromProgram join always uses
> chanid, there won't always be oldrecorded entries for it to match.
> A solution for that is to have PruneReduntants call AddHistory (only
> for status changes) before deleting a PI.  Then all oldrecstatus joins
> on oldrecorded could always use chanid.  The downside would be an
> increase in the number of oldrecorded entries.  I don't particularly
> like that, but it might be unavoidable.

Well, I tried that, or at least what I thought you meant, but I most
have done something terribly wrong.  I added a call to AddHistory in
PruneRedunants, right before the second call to delete.  That added
entries to oldrecorded for future programs, though, which I don't
think is what was intended.  This must need to be qualified more to
work.  These records then screwed up the scheduler, and put the whole
thing into a downward spiral...

Argh.  Just when I sort of thought I knew what was going on in this
code, I suddenly feel way out of my depth again...

Is the work in FromProgram all in the name of getting accurate
statuses on past programs in the EPG, or is that needed for some other

More information about the mythtv-dev mailing list