[mythtv] [PATCH] Control duplicates by channel ID

[David Shay]

On 8/9/07, David Engel <david at istwok.net> wrote:
> On Wed, Aug 08, 2007 at 11:52:29PM -0500, David Shay wrote:
> > I'm not ready to give up yet (because I REALLY want to use this...I
> > was recording HD and SDTV for a while and had to keep adding override
>
> I'm not asking you to give.  I was mainly throwing something out there
> in hopes of sparking a new idea.
>
> > entries to make it work, since I still wanted to take advantage of
> > duplicate detection).  From my perspective, if we can figure out how
> > to get all relevant entries into oldrecorded, I think the rest will
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (* see below)
>
> > How about inserting a new function when the recording starts that
> > inserts the appropriate additional rows.  It could find other showings
> > on at the same time, check their current status in oldrecorded, and
> > [...]
>
> This all hinges on changing oldrecorded to index on chanid instead of
> callsign.  If that change is made, I think the rest of the scheduler
> needs to also change to fundamentally group things by chanid.
> Anything less will be madness, IMO.

I'm not sure.  I had hoped initially that changing the key wouldn't be
that large of a problem since most of the calls were qualified by
chanid already.  I still am going to do more exploring on how you
could get those oldrecorded entries in there somehow.  Maybe that's
still just putting one more finger in the dike -- I don't know.

>
> (*) This might have sparked one of those ideas.  Instead of changing
> oldrecorded to match our special case data, let's change our special
> case data to use the existing oldrecorded but still achieve the
> desired result.  My local NBC affiliate is KXAS and shows up as
> chanids 1005, 3101 and 3131 for me.  What if for these special rules,
> and only these special rules, the scheduler saw callsigns like
> "KXAS/1005", "KXAS/3101" and "KXAS/3131" for the respective chanids
> instead of them all being the same "KXAS"?  Voila, the indexing
> problem on oldrecorded goes away.
>

This is definitely an interesting "out of the box" thought.  I haven't
played it all the way out yet.   My first glance was at the
oldrecorded/oldstatus join in FromProgram, which is what was biting us
in the current situation.  If we change the callsign in oldrecorded to
be the concantenated value, the join from program would fail (since in
program it would not be manipulated, I would assume you would
manipulate it in "record", though).  Since the join would fail, it
would not pick up the oldrecorded status.  I suppose it might be
possible to craft the join in such a way, though that you joined on
either the straight callsign match *or* the concatentated
callsign/chanid match.  That might make it work for there.  I'll think
on this some more.

Also, I suppose we would have to increase the length of station in
recorded/oldrecorded on the offchance that somebody has really long
callsign values, or trim them to a length of 15 before concatenating .
Trimming would make doing the join in SQL like above harder, but that
might be the only place where the SQL simulation of this would be
necessary.  Again, I've only contemplated it for a little bit.  This
will add even more conditional logic on dupchanid to now manipulate
callsigns as well as manipulating duplicate logic, but that might be
fine.

Haven't gotten back to code anything the last few days, nor will I
until next week at the rate work is going, but I'll keep mulling it
over.