[mythtv] [PATCH] Control duplicates by channel ID

[David Shay]

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

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
get a record entry in via the GUI, but if we can do that, I *think*
the scheduler *might* now work...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dupchanid-4.patch.gz
Type: application/x-gzip
Size: 5363 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070804/6c4c8c2c/attachment.bin