[mythtv] [PATCH] Control duplicates by channel ID

David Shay david at shay.net
Sun Aug 5 12:42:42 UTC 2007


On 8/4/07, David Shay <david at shay.net> wrote:
> On 8/4/07, Bruce Markey <bjm at lvcm.com> wrote:
> > David Shay wrote:
> > ...
> > > OK.  Coding/Testing at 3AM was a bad idea. I was testing with the same
> > > chanid and same callsign.  I started testing with different chanid's
> > > and the same callsign and found more issues, but I think I've fixed
> > > them now, at least within the scheduler.  I still don't know how to
> >
> > Yeah, this has the basics working. Good job.
> >
> > > get a record entry in via the GUI, but if we can do that, I *think*
> > > the scheduler *might* now work...
> >
> > I'm not sure what you mean.
> >
> > > I tested this by forcing a new "record" entry in with the same
> > > callsign.  I still couldn't get one in.  In fact, I'm not sure what
> > > the right GUI for this should be.  For instance, if you are coming in
> > > from the program guide, and you already have one defined, but the
> > > "consider channel id is set", maybe there is another button choice
> > > added to the list that says "add new rule for same channel/callsign".
> >
> > Here's another example of why I make a big deal about channel
> > (frequency) and station (building), things quickly become "who's
> > on first?". You can not create a second rule for the same
> > (frequency)/(station). You need to create two different rules
> > for two (frequency)/(station) pairs i.e. 8/KLAS (1008) and 128/KLAS
> > (2128).
> ...
>
> Um, Yeah. How do I say this. I MADE THE SAME STUPID MISTAKE AGAIN. It
> all works fine now, at least when you use it right. I've been testing
> this on a "test" system, which is actually in a different city than my
> production system and I've had many challenges with that.  I don't
> really have the same situation/setup there.  I've got a DVB tuner
> instead of HDHomerun's, and I didn't have all the SDTV versions of the
> channels over QAM mapped to the DVB tuner, and then I did, but had
> failed to run mythfilldatabase again.  Anyway, long story short,
> forget anything I ever said about that piece not working or about
> needing a different GUI option.
>
> I'll do some additional checking about recorded/oldrecorded entries to
> see if anything is getting screwed up there.  I don't even think I
> touched anything related to that, but I'm not really sure where all
> the tentacles go.
>
> What are the remaining steps/open items, then?
>
> The ones I know of are:
>
> * Continued testing for recorded/oldrecorded.

Determined what at least one of the problems here is.  The primary key
to oldrecorded does not include chanid. This makes the "REPLACE"
statement in AddHistory not add a new record when it now should.  I'm
not sure if there would be any other impacts of just adding chanid
into the key for oldrecorded.

I'm pretty sure there are some other cases where things could go wrong
as well in the calls to AddHistory, particularly where
IsSameProgramTimeslot is called on a pointer to a PI structure.  There
the checks don't take chanid into account.  In my current code I've
added some additional checks.  I think those are still necessary to
get the status updates working correctly  Those weren't fixing the
core problem of the missing row, though.  Once I've got changed the
key structure and validated that that doesn't break anything else,
I'll get another patch out.



> * Cleaning up the GUI -- Do I make the height one option higher to
> account for the new select box?
> * Cleaning up the GUI -- Any suggestions on wording of the options,
> both on the recording details screen as well as in MythWeb ?
>
> Thanks.
>


More information about the mythtv-dev mailing list