[mythtv] [PATCH] Control duplicates by channel ID

[David Shay]

On 8/4/07, David Shay <david at shay.net> wrote:
> On 8/3/07, Bruce Markey <bjm at lvcm.com> wrote:
> > I had some time this afternoon to play with dupchanid-2.patch
> > and hope to find more time over the weekend. The patch itself
> > looked good. The wording and scrolling on the options page
> > should be fixed but these are cosmetic. However, as far as
> > using this, I didn't get off the ground yet...
> >
> > David Shay wrote:
> > > Attached is a patch that controls duplicates by channel ID.
> > >
> > > It adds a new option to the Scheduling Options recording rule screen
> > > that can be set to either "Match duplicates Ignoring Channel ID"
> > > (which is the current behavior), or the new behavior "Match duplicates
> > > considering channel ID".
> > >
> > > You can then setup multiple record rules that either specify certain
> > > channels or prefer certain inputs, and if the new match duplicates
> > > setting is selected, you will get multiple copies of the same show.
> > > My primary purpose for the patch is to be able to record both a
> > > high-def and low-def version of the same show, but there are many
> > > other uses as well as pointed out in other threads.
> > >
> > > I've created a new field called "dupchanid" in programinfo that
> > > controls this with two new constant values -- kDupIgnoreChanID and
> > > kDupConsiderChanID.  Yes, it could have been a boolean, but I
> > > purposely did it this way so that it could be extensible later to
> > > other things, such as just source ID or some other variant just by
> > > setting new values. (perhaps the field shouldn't be called dupchanid,
> > > then -- let me know if you've got a better name for it)  I've added
> > > these to the to and from string lists and updated the protocol to
> > > version 36 with this patch.  There is a a new field called dupchanid
> > > in the record table as well, so an update to dbcheck.cpp is included
> > > as well.
> > >
> > > The main changes to get this implemented were in the big scheduler
> > > query in scheduler.cpp as well as in IsSameProgram in programinfo.cpp.
> > >
> > > I've tested this with and without programid's, and for both programs
> > > on at the same time as well as those that are on at different times,
> > > and it "works for me".  Please test and give me feedback.
> >
> > Can I assume that you are using mismatched callsigns? With
> > matching callsigns, there are issues from the get go.
> >
> > First, the recordmatch table should only match showings for
> > the one chanid if dupchanid is set. I did a quick hack in
> > UpdateMatches():
> >
> > @@ -2034,6 +2034,7 @@
> >             "                                      OR program.first = 0))) ")
> >             .arg(kDupsExRepeats).arg(kDupsExGeneric).arg(kDupsFirstNew) +
> >     QString(" AND channel.visible = 1 AND "
> > +"(RECTABLE.dupchanid = 0 OR RECTABLE.chanid = program.chanid) AND "
> >  "((RECTABLE.type = %1 " // allrecord
> >  "OR RECTABLE.type = %2 " // findonerecord
> >  "OR RECTABLE.type = %3 " // finddailyrecord
> >
> > This seems to do the job:
> >
> > mysql> select * from recordmatch where recordid=1325 order by starttime;
> > +----------+--------+---------------------+----------+
> > | recordid | chanid | starttime           | manualid |
> > +----------+--------+---------------------+----------+
> > |     1325 |   1003 | 2007-08-03 18:30:00 |        0 |
> > |     1325 |   2123 | 2007-08-03 18:30:00 |        0 |
> > |     1325 |   1003 | 2007-08-10 18:30:00 |        0 |
> > |     1325 |   2123 | 2007-08-10 18:30:00 |        0 |
> > +----------+--------+---------------------+----------+
> > 4 rows in set (0.00 sec)
> >
> > mysql> select * from recordmatch where recordid=1325 order by starttime;
> > +----------+--------+---------------------+----------+
> > | recordid | chanid | starttime           | manualid |
> > +----------+--------+---------------------+----------+
> > |     1325 |   1003 | 2007-08-03 18:30:00 |        0 |
> > |     1325 |   1003 | 2007-08-10 18:30:00 |        0 |
> > +----------+--------+---------------------+----------+
> > 2 rows in set (0.01 sec)
> >
> > The next problem was that the scheduling pages listed
> > showings on the other chanid(s) as instances for the
> > first rule preventing adding a second rule. This is pretty
> > much the same hack for FromProgram() in programinfo.cpp:
> >
> > @@ -4609,7 +4622,8 @@
> >         ProgramInfo *s;
> >         for (s = schedList.first(); s; s = schedList.next())
> >         {
> > -            if (p->IsSameTimeslot(*s))
> > +            if (p->IsSameTimeslot(*s) &&
> > +                (s->dupchanid == 0 || p->chanid == s->chanid))
> >             {
> >                 p->recordid = s->recordid;
> >                 p->recstatus = s->recstatus;
> >
> >
> > I didn't get further than that before needing my machines for
> > the evening. I'll play with it some more...
> >
> >
> Attached are two new patches that address some of this but not all of it.
>
> * Includes your two lines from above
> * One additional change to PruneRedundants that I think makes it
> finally schedule OK with the same callsign
> * Rest of protocol changes for perl bindings and Mythweb
> * Support for setting the flag via Mythweb
>
> 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".
> Were you able to get a rule in with your change above or not?  Does
> that GUI option make sense?
>
> FYI, I used "build_translation.pl" according to the directions in
> mythweb since I added some new text.  That appeared to delete quite a
> few entries in the translation tables.  Upon further checking, they
> are indeed now unused.  Chris Petersen, looking for any advice on
> whether that's OK or not...  The attached mythweb patch includes all
> of those deletions.  I didn't really add that much text, so I could
> add those entries to all of the languages manually, I suppose.  What
> has been the approach recently?
>
>

Ugh.  Upon further checking, It got past PruneRedundants, but it's
still getting marked as "Later Showing" (for same callsign -- still
works fine for different callsigns).  I'm hanging it up for the night.
 Let me know if you get a chance to look at it at all.