[mythtv] [PATCH] Control duplicates by channel ID

[David Shay]

On 8/5/07, Bruce Markey <bjm at lvcm.com> wrote:
> David Shay wrote:
> ...
> > If this analysis is correct, attached is the latest patch that
> > includes the update to dbcheck.cpp.  I didn't phase out
> > IsSameProgramTimeslot, but just qualified it with the dupchanid and
> > chanid checks.
> >
> > Let me know.
>
> Some quick 'good' testing. I found some things to check into
> for 'bad' testing but here's the good news for today =).
>
> Created rules for 'Whacked Out Sports' for 3 KVBC and 123 KVBC.
> at 3:30. Set both to start 10min late and one to end 10min early.
> At 3:40 both started recording.
>
> mysql> select recordid,recstatus,chanid,station,title from oldrecorded where title = 'Whacked Out Sports';
> +----------+-----------+--------+---------+--------------------+
> | recordid | recstatus | chanid | station | title              |
> +----------+-----------+--------+---------+--------------------+
> |     1332 |        -2 |   1003 | KVBC    | Whacked Out Sports |
> |     1333 |        -2 |   2123 | KVBC    | Whacked Out Sports |
> +----------+-----------+--------+---------+--------------------+
>
> A few minutes in, I killed the master with 2123 while a slave
> continued to record 1003. I restarted the MBE expecting that it
> would find the slave and restart 2123 locally. However, the
> connection was late and the slave's card wasn't included in the
> reclist of the first schedule run (but was included on the next
> run several second later). Because the master considered the slave
> as unreachable, it did the right thing (for that circumstance) and
> restarted 2123 plus 1003 on another available local card(!).

I'm not even aware of all of these "scenarios/prototyping
cases/conditions" (that's what we'd call them at work...) that need to
be tested for.  You and David Engel probably have the most knowledge
there.  I'm not set up with a slave backend right now to test the more
complex ones, either.  I'm not sure if the problem you say with
something not being in the first run but being picked up in a
subsequent one is something in one of those conditions mentioned above
that I commented on, and if so, which one...

>
> At 3:50, 1332 stopped as it was set to end 10min early while
> 1333 on 2123 continued to record:
>
> mysql> select recordid,recstatus,chanid,station,title from oldrecorded where title = 'Whacked Out Sports';
> +----------+-----------+--------+---------+--------------------+
> | recordid | recstatus | chanid | station | title              |
> +----------+-----------+--------+---------+--------------------+
> |     1332 |        -3 |   1003 | KVBC    | Whacked Out Sports |
> |     1333 |        -2 |   2123 | KVBC    | Whacked Out Sports |
> +----------+-----------+--------+---------+--------------------+
>
> So it looks like the basics work.
>
>
>
> One quick observation, search rules always have record.chanid=0.
> That ought to be solvable but I'm still pondering...
>

Hmm.  Hadn't thought about that. The whole point is you don't
necessarily know the channel going into it, right?.  Maybe this just
isn't relevant and should be disabled?

> PowerPriority was broken (HD priority, prefinput, etc.)
>
> -        p->recpriority2 = result.value(45).toInt();
> +        p->recpriority2 = result.value(46).toInt();

Fixed in attached patch.  It was only later that I figured out how
that even worked that it was actually adding another column...

>
> Oh, "Channel ID" isn't really end user terminology and "consider"
> and "ignoring" are confusing even when I know what's supposed to
> happen. How about "Match duplicates from any channel" and "Match
> duplicates only from this channel"? I'm not sold that this is the
> best wording but the idea should be 'anything' vs 'this specific
> channel'.
>

Changed in attach patch for mythtv itself.  Once everything else is
working, I can create another patch with a final patch for
mythplugins/mythweb.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dupchanid-6.patch.gz
Type: application/x-gzip
Size: 5826 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070805/87e61c04/attachment.bin