Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

[PATCH] Control duplicates by channel ID

 

 

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded


david at shay

Aug 2, 2007, 9:49 PM

Post #1 of 35 (4992 views)
Permalink
[PATCH] Control duplicates by channel ID

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.

Thanks.
Attachments: dupchanid.patch.gz (3.90 KB)


david at shay

Aug 2, 2007, 10:06 PM

Post #2 of 35 (4889 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

Had some duplicate lines in the scheduler query that weren't causing
any problems but were wrong.

Here's the updated patch. Please use this one for testing,
Attachments: dupchanid-2.patch.gz (3.79 KB)


bjm at lvcm

Aug 3, 2007, 7:06 PM

Post #3 of 35 (4873 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

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...

-- bjm





_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 3, 2007, 7:30 PM

Post #4 of 35 (4880 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/3/07, Bruce Markey <bjm [at] lvcm> 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.

Any recommendations on wording? That way I can get that in and
consistent in both this and mythweb.

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.
>

Yes. Obviously I was in "selfish mode" testing my primary usage and
forgot to test the same-callsign scenario.

> 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...
>

Thanks for those updates. I'll put those updates in tonight and do
more testing with the same-callsign scenario. I've also got more in
the patch now including the perl-bindings update for the protocol, and
Mythweb updates for the protocol and ability to set the flag from
Mythweb. I'll get another patch out tonight hopefully.

> -- bjm
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 3, 2007, 11:47 PM

Post #5 of 35 (4858 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/3/07, Bruce Markey <bjm [at] lvcm> 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?
Attachments: dupchanid-3.patch.gz (4.78 KB)
  dupchanid-plugin.patch.gz (16.2 KB)


david at shay

Aug 3, 2007, 11:58 PM

Post #6 of 35 (4853 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/4/07, David Shay <david [at] shay> wrote:
> On 8/3/07, Bruce Markey <bjm [at] lvcm> 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.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 4, 2007, 8:51 AM

Post #7 of 35 (4872 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/4/07, David Shay <david [at] shay> wrote:
> On 8/4/07, David Shay <david [at] shay> wrote:
> > On 8/3/07, Bruce Markey <bjm [at] lvcm> 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...
Attachments: dupchanid-4.patch.gz (5.24 KB)


bjm at lvcm

Aug 4, 2007, 10:29 AM

Post #8 of 35 (4870 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

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).

> Were you able to get a rule in with your change above or not?

Yes, with your patch 4. The point of the FromProgram() change was
that the scheduling pages should not mark a status for instances
on other chanids. Therefore, I can add another rule on a showing
from another chanid. Before they were marked "O" for the recordid
of the rule on the other chanid.

If I go to the EPG or any proglist page and set a rule for one
chanid, showings on other chanids are rsUnknown and I can add
another rule for the same show for that chanid only also. I added
a rule for "Teen Kids News"

8/4 9:30 am 8 KLAS Teen Kids News 2
8/4 9:30 am 128 KLAS Teen Kids News -
8/4 12:00 am 19 LV1 Teen Kids News -
8/11 9:30 am 8 KLAS Teen Kids News 2
8/11 9:30 am 128 KLAS Teen Kids News -
8/11 12:00 am 19 LV1 Teen Kids News -

I then clicked "I" on the second line and made a second dupchanid
rule:

8/4 9:30 am 8 KLAS Teen Kids News 2
8/4 9:30 am 128 KLAS Teen Kids News 1
8/4 12:00 am 19 LV1 Teen Kids News -
8/11 9:30 am 8 KLAS Teen Kids News 2
8/11 9:30 am 128 KLAS Teen Kids News 1
8/11 12:00 am 19 LV1 Teen Kids News -

mysql> select recordid,dupchanid,chanid,title from record where title = 'Teen Kids News';
+----------+-----------+--------+----------------+
| recordid | dupchanid | chanid | title |
+----------+-----------+--------+----------------+
| 1328 | 1 | 1008 | Teen Kids News |
| 1329 | 1 | 2128 | Teen Kids News |
+----------+-----------+--------+----------------+
2 rows in set (0.02 sec)

2007-08-04 09:23:57.402 Using protocol version 36
Retrieving Schedule from Master backend.
--- print list start ---
Title - Subtitle Ch Station Day Start End S C I T N Pri
Teen Kids News 8 KLAS 04 09:30-10:00 1 2 3 A 2 1/0
Teen Kids News 128 KLAS 04 09:30-10:00 2 1 1 A 1 1/0
The Soup 36 ETVP 04 10:00-10:30 1 0 0 w P -5/0
PGA Golf - "WGC Bridgestone In 128 KLAS 04 10:00-15:29 2 1 1 A 1 0/0

Both wre scheduled to record and at 9:30 both did record. However,
only one entry was added to oldrecorded:

mysql> select recordid,chanid,station,programid,title from oldrecorded where title = 'Teen Kids News';
+----------+--------+---------+--------------+----------------+
| recordid | chanid | station | programid | title |
+----------+--------+---------+--------------+----------------+
| 1329 | 2128 | KLAS | EP5987610168 | Teen Kids News |
+----------+--------+---------+--------------+----------------+
1 row in set (0.00 sec)

There need to two entries to track that this has recorded on
both 8 and 128. Presumably another showing on 8 would re-record
becuase there is no 1328/1008/KLAS/EP5987610168/Teen Kids News
entry. So, I stopped both recording then restarted to MBE. I
expected that the 128/KLAS would be marked as rsRecorded and
the 8/KLAS would reactivate because there is no matching
oldrecorded entry but they were both marked "R". [.I now realize
that there was a 'recorded' entry which is why it was "R". I'll
have to try this again later.]

-- bjm



_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 4, 2007, 4:19 PM

Post #9 of 35 (4876 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/4/07, Bruce Markey <bjm [at] lvcm> 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.
* 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.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 5, 2007, 5:42 AM

Post #10 of 35 (4860 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/4/07, David Shay <david [at] shay> wrote:
> On 8/4/07, Bruce Markey <bjm [at] lvcm> 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.
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Aug 5, 2007, 10:01 AM

Post #11 of 35 (4860 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On Sun, Aug 05, 2007 at 07:42:42AM -0500, David Shay wrote:
> 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.

Oh, shoot. Yes, oldrecorded imposes the restriction of one entry per
title, starttime and callsign. The scheduler relies on this when
restoring any previous status for programs that aren't currently
recording and for catching reactivation requests. I'd be very
concerned about the impact of allowing additional entries per chanid
on this functionality.

> 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

I think IsSameProgramTimeslot is a hold over from long ago when the
program start and times weren't kept around and only the recording
times available. The IsSameProgramTimeslot check was made fuzzy to
allow for differences in the recording times that could creep in
between the scheduler and the recorders. It looks like
Scheduler::UpdateRecStatus is the only remaining user of
IsSameProgramTimeslot and it can probably be replaced with
IsSameProgram now.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 5, 2007, 12:06 PM

Post #12 of 35 (4864 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/5/07, David Engel <david [at] istwok> wrote:
> On Sun, Aug 05, 2007 at 07:42:42AM -0500, David Shay wrote:
> > 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.
>
> Oh, shoot. Yes, oldrecorded imposes the restriction of one entry per
> title, starttime and callsign. The scheduler relies on this when
> restoring any previous status for programs that aren't currently
> recording and for catching reactivation requests. I'd be very
> concerned about the impact of allowing additional entries per chanid
> on this functionality.
>

Seems like oldrecorded primarily gets updated by the start of
RunScheduler, where everything gets set to rsAborted, and then
subsequent calls to AddHistory.

I've done a quick analysis of where AddHistory is called within
scheduler.cpp. (The only one outside is in tv_rec.cpp, and it's OK).
Here's where it's called:

UpdateRecStatus (the pointer to ProgramInfo version)
Could be changed to use IsSameProgram instead of
IsSameProgramTimeslot and this might be OK?

UpdateRecStatus(cardid, chanid,startts,recstatus,endts)
Already being qualified by chanid check, should be OK?

SlaveConnected
First two calls are being qualified by cardid already. This happens
in many later calls, as well. My assumption is that if it's already
qualified by cardid, that should be sufficient and no additional
qualification by chanid would be necessary.

The last call is not qualified by anything, but that seems to just be the
fall-through case. I wouldn't think this one would be disturbed by the
index not being there, but I don't know. In what case would that matter?

SlaveDisconnected
This call is qualified by cardid.

AddRecording
Was using IsSameProgramTimeslot. I guess this should also be
changed to IsSameProgram?

RunScheduler
Around line 1411 now, there is a check for if nextrecording->recstatus
!= rsWillRecord, then AddHistory gets called. I'm not sure from this code,
what status nextrecording would even get set to?

The next call is qualified by cardid.
The next call is based on IsTunerLocked, should be OK.
The last call is unqualified, but I think should be OK, since it is just in
the main loop through the PI records.

Seems to me like even those unqualified calls are OK, and that the
ones qualified by cardid are OK as well.

ReactivateRecording within programinfo.cpp would need to get changed
to also pass chanid as a parameter as well. But apparently that only
gets called from the GUI, not the scheduler.

> > 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
>
> I think IsSameProgramTimeslot is a hold over from long ago when the
> program start and times weren't kept around and only the recording
> times available. The IsSameProgramTimeslot check was made fuzzy to
> allow for differences in the recording times that could creep in
> between the scheduler and the recorders. It looks like
> Scheduler::UpdateRecStatus is the only remaining user of
> IsSameProgramTimeslot and it can probably be replaced with
> IsSameProgram now.


So you are saying if you had pre-roll/post-roll kinds of things,
that's what it would be used for? Right now, anyway,
IsSameProgramTimeslot looks to make sure that the given program is
wholly contained within the other program, and matches on title and
chanid. The only thing I'm a little concerned about is that
IsSameProgram does no element of time checking at all. Wouldn't that
be a problem?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 5, 2007, 12:47 PM

Post #13 of 35 (4849 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/5/07, David Shay <david [at] shay> wrote:
> On 8/5/07, David Engel <david [at] istwok> wrote:
> > On Sun, Aug 05, 2007 at 07:42:42AM -0500, David Shay wrote:
> > > 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.
> >
> > Oh, shoot. Yes, oldrecorded imposes the restriction of one entry per
> > title, starttime and callsign. The scheduler relies on this when
> > restoring any previous status for programs that aren't currently
> > recording and for catching reactivation requests. I'd be very
> > concerned about the impact of allowing additional entries per chanid
> > on this functionality.
> >
>
> Seems like oldrecorded primarily gets updated by the start of
> RunScheduler, where everything gets set to rsAborted, and then
> subsequent calls to AddHistory.
>
> I've done a quick analysis of where AddHistory is called within
> scheduler.cpp. (The only one outside is in tv_rec.cpp, and it's OK).
> Here's where it's called:
>
> UpdateRecStatus (the pointer to ProgramInfo version)
> Could be changed to use IsSameProgram instead of
> IsSameProgramTimeslot and this might be OK?
>
> UpdateRecStatus(cardid, chanid,startts,recstatus,endts)
> Already being qualified by chanid check, should be OK?
>
> SlaveConnected
> First two calls are being qualified by cardid already. This happens
> in many later calls, as well. My assumption is that if it's already
> qualified by cardid, that should be sufficient and no additional
> qualification by chanid would be necessary.
>
> The last call is not qualified by anything, but that seems to just be the
> fall-through case. I wouldn't think this one would be disturbed by the
> index not being there, but I don't know. In what case would that matter?
>
> SlaveDisconnected
> This call is qualified by cardid.
>
> AddRecording
> Was using IsSameProgramTimeslot. I guess this should also be
> changed to IsSameProgram?
>
> RunScheduler
> Around line 1411 now, there is a check for if nextrecording->recstatus
> != rsWillRecord, then AddHistory gets called. I'm not sure from this code,
> what status nextrecording would even get set to?
>
> The next call is qualified by cardid.
> The next call is based on IsTunerLocked, should be OK.
> The last call is unqualified, but I think should be OK, since it is just in
> the main loop through the PI records.
>
> Seems to me like even those unqualified calls are OK, and that the
> ones qualified by cardid are OK as well.
>
> ReactivateRecording within programinfo.cpp would need to get changed
> to also pass chanid as a parameter as well. But apparently that only
> gets called from the GUI, not the scheduler.
>
> > > 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
> >
> > I think IsSameProgramTimeslot is a hold over from long ago when the
> > program start and times weren't kept around and only the recording
> > times available. The IsSameProgramTimeslot check was made fuzzy to
> > allow for differences in the recording times that could creep in
> > between the scheduler and the recorders. It looks like
> > Scheduler::UpdateRecStatus is the only remaining user of
> > IsSameProgramTimeslot and it can probably be replaced with
> > IsSameProgram now.
>
>
> So you are saying if you had pre-roll/post-roll kinds of things,
> that's what it would be used for? Right now, anyway,
> IsSameProgramTimeslot looks to make sure that the given program is
> wholly contained within the other program, and matches on title and
> chanid. The only thing I'm a little concerned about is that
> IsSameProgram does no element of time checking at all. Wouldn't that
> be a problem?
>

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.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 5, 2007, 12:49 PM

Post #14 of 35 (4869 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

Sorry, this is the attached patch from the last message.
Attachments: dupchanid-5.patch.gz (5.62 KB)


bjm at lvcm

Aug 5, 2007, 5:31 PM

Post #15 of 35 (4847 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

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(!).

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...

PowerPriority was broken (HD priority, prefinput, etc.)

- p->recpriority2 = result.value(45).toInt();
+ p->recpriority2 = result.value(46).toInt();

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'.

-- bjm

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 5, 2007, 8:08 PM

Post #16 of 35 (4853 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/5/07, Bruce Markey <bjm [at] lvcm> 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.
Attachments: dupchanid-6.patch.gz (5.69 KB)


david at istwok

Aug 5, 2007, 9:30 PM

Post #17 of 35 (4847 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On Sun, Aug 05, 2007 at 03:06:32PM -0400, David Shay wrote:
> UpdateRecStatus (the pointer to ProgramInfo version)
> Could be changed to use IsSameProgram instead of
> IsSameProgramTimeslot and this might be OK?

See below.

> UpdateRecStatus(cardid, chanid,startts,recstatus,endts)
> Already being qualified by chanid check, should be OK?
>
> SlaveConnected
> First two calls are being qualified by cardid already. This happens
> in many later calls, as well. My assumption is that if it's already
> qualified by cardid, that should be sufficient and no additional
> qualification by chanid would be necessary.
>
> The last call is not qualified by anything, but that seems to just be the
> fall-through case. I wouldn't think this one would be disturbed by the
> index not being there, but I don't know. In what case would that matter?
>
> SlaveDisconnected
> This call is qualified by cardid.
>
> AddRecording
> Was using IsSameProgramTimeslot. I guess this should also be
> changed to IsSameProgram?

Yes for all of these, I think, as far as IsSameProgram is concerned.
Not related to this, however, I think some of those cardid checks
should be cardid and inputid checks. It's probably highly unlikely,
but I suppose it is possible the same chanid could be on multiple
inputs on the same card.

> RunScheduler
> Around line 1411 now, there is a check for if nextrecording->recstatus
> != rsWillRecord, then AddHistory gets called. I'm not sure from this code,
> what status nextrecording would even get set to?

Is that the case which is also qualified by recstatus != oldrecstatus?
If so that's to catch status changes when a program is reactivated and
possibly some others I can't remember off the top of my head.

> Seems to me like even those unqualified calls are OK, and that the
> ones qualified by cardid are OK as well.
>
> ReactivateRecording within programinfo.cpp would need to get changed
> to also pass chanid as a parameter as well. But apparently that only
> gets called from the GUI, not the scheduler.

I think you're missing the other use of oldrecorded that I mentioned
earlier. Please see the oldrecstatus join in the scheduler query.

When a reschedule is done, the scheduler only keeps entries for
currently recording programs in memory. The scheduler re-reads the
state for any programs which are currently being shown but have
already been dispositioned from the oldrecorded table. Reactivation
requests are also pulled in in this way.

The old state and reactivation values come from the oldrecstatus join
in the scheduler query. This join intentionally only uses callsign
because, until now, with the exception actually choosing which card,
input and chanid to record on, the same program from the same station
was always treated the no matter what chanid it was on.

Additionally, PL::FromProgram uses a similar join to read the status
of past programs the scheduler no longer cares about. This is how the
EPG can show the recording status for yesterday's programs.

It is the impact of having multiple chanid entries in oldrecrded on
these uses that I am concerned about. If nothing special is done,
those queries could start returning duplicate results. Perhaps any
duplicates would be harmless and everything would come out in the
wash. I don't know yet.

OK, so what do we do?

ONe option is to do away with all of the coalescing we do on callsign
and callsign/channel number. ViewScheduled would always show multiple
entries for the same program on different chanids, even if the channel
number is the same. Likewise, oldrecorded would always show multiple
entries.

Change the scheduler to make the oldrecstatus join condition smarter
to use chanid when applicable and not when it isn't. I'm not sure
PL::FromProgram could do this since the recordid wouldn't be available
until after the join.

> So you are saying if you had pre-roll/post-roll kinds of things,
> that's what it would be used for?

Any number of things -- pre/post-roll, start-early/end-late, not
asking to record a record a program until after it's started,
reactivating a stopped program.

> Right now, anyway,
> IsSameProgramTimeslot looks to make sure that the given program is
> wholly contained within the other program, and matches on title and
> chanid.

Not wholly contained, just overlapping.

> The only thing I'm a little concerned about is that
> IsSameProgram does no element of time checking at all. Wouldn't that
> be a problem?

Now it's my turn to be missing something! :( I was completely wrong
before in saying IsSameProgramTimeslot could be replaced with
IsSameProgram. The should be replaced with IsSameTimeslot. My bad.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 6, 2007, 4:05 AM

Post #18 of 35 (4851 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/5/07, David Engel <david [at] istwok> wrote:
> On Sun, Aug 05, 2007 at 03:06:32PM -0400, David Shay wrote:
> > UpdateRecStatus (the pointer to ProgramInfo version)
> > Could be changed to use IsSameProgram instead of
> > IsSameProgramTimeslot and this might be OK?
>
> See below.
>
> > UpdateRecStatus(cardid, chanid,startts,recstatus,endts)
> > Already being qualified by chanid check, should be OK?
> >
> > SlaveConnected
> > First two calls are being qualified by cardid already. This happens
> > in many later calls, as well. My assumption is that if it's already
> > qualified by cardid, that should be sufficient and no additional
> > qualification by chanid would be necessary.
> >
> > The last call is not qualified by anything, but that seems to just be the
> > fall-through case. I wouldn't think this one would be disturbed by the
> > index not being there, but I don't know. In what case would that matter?
> >
> > SlaveDisconnected
> > This call is qualified by cardid.
> >
> > AddRecording
> > Was using IsSameProgramTimeslot. I guess this should also be
> > changed to IsSameProgram?
>
> Yes for all of these, I think, as far as IsSameProgram is concerned.
> Not related to this, however, I think some of those cardid checks
> should be cardid and inputid checks. It's probably highly unlikely,
> but I suppose it is possible the same chanid could be on multiple
> inputs on the same card.
>
> > RunScheduler
> > Around line 1411 now, there is a check for if nextrecording->recstatus
> > != rsWillRecord, then AddHistory gets called. I'm not sure from this code,
> > what status nextrecording would even get set to?
>
> Is that the case which is also qualified by recstatus != oldrecstatus?
> If so that's to catch status changes when a program is reactivated and
> possibly some others I can't remember off the top of my head.

Yes, that's the one. The thing that was confusing is that in most
cases, before AddHistory is called, recstatus is set to something. In
this case, it is just called without setting recstatus at all.


>
> > Seems to me like even those unqualified calls are OK, and that the
> > ones qualified by cardid are OK as well.
> >
> > ReactivateRecording within programinfo.cpp would need to get changed
> > to also pass chanid as a parameter as well. But apparently that only
> > gets called from the GUI, not the scheduler.
>
> I think you're missing the other use of oldrecorded that I mentioned
> earlier. Please see the oldrecstatus join in the scheduler query.
>

Right, I hadn't seen the oldrecstatus join, only the main oldrecorded
join. See below for other comments.

> When a reschedule is done, the scheduler only keeps entries for
> currently recording programs in memory. The scheduler re-reads the
> state for any programs which are currently being shown but have
> already been dispositioned from the oldrecorded table. Reactivation
> requests are also pulled in in this way.
>
> The old state and reactivation values come from the oldrecstatus join
> in the scheduler query. This join intentionally only uses callsign
> because, until now, with the exception actually choosing which card,
> input and chanid to record on, the same program from the same station
> was always treated the no matter what chanid it was on.
>
> Additionally, PL::FromProgram uses a similar join to read the status
> of past programs the scheduler no longer cares about. This is how the
> EPG can show the recording status for yesterday's programs.
>
> It is the impact of having multiple chanid entries in oldrecrded on
> these uses that I am concerned about. If nothing special is done,
> those queries could start returning duplicate results. Perhaps any
> duplicates would be harmless and everything would come out in the
> wash. I don't know yet.
>
> OK, so what do we do?
>
> ONe option is to do away with all of the coalescing we do on callsign
> and callsign/channel number. ViewScheduled would always show multiple
> entries for the same program on different chanids, even if the channel
> number is the same. Likewise, oldrecorded would always show multiple
> entries.
>
> Change the scheduler to make the oldrecstatus join condition smarter
> to use chanid when applicable and not when it isn't.

That seems like the right/easiest thing to do within the scheduler,
since we already have the information and it's consistent with the
other joins to oldrecorded and recorded.

>I'm not sure
> PL::FromProgram could do this since the recordid wouldn't be available
> until after the join.

Right. However, Bruce earlier added code to insert the additional
check after the query to verify on dupchanid and check the chanid's.
That still doesn't guarantee the right status for programs in the
past, though. What about "hardcoding" a forced join on chanid, just
for FromProgram?

>
> > So you are saying if you had pre-roll/post-roll kinds of things,
> > that's what it would be used for?
>
> Any number of things -- pre/post-roll, start-early/end-late, not
> asking to record a record a program until after it's started,
> reactivating a stopped program.
>
> > Right now, anyway,
> > IsSameProgramTimeslot looks to make sure that the given program is
> > wholly contained within the other program, and matches on title and
> > chanid.
>
> Not wholly contained, just overlapping.
>
> > The only thing I'm a little concerned about is that
> > IsSameProgram does no element of time checking at all. Wouldn't that
> > be a problem?
>
> Now it's my turn to be missing something! :( I was completely wrong
> before in saying IsSameProgramTimeslot could be replaced with
> IsSameProgram. The should be replaced with IsSameTimeslot. My bad.
>

That makes more sense. Gee, such a simple topic, not sure how anyone
could get confused :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Aug 6, 2007, 11:58 AM

Post #19 of 35 (4828 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On Mon, Aug 06, 2007 at 06:05:16AM -0500, David Shay wrote:
> >I'm not sure
> > PL::FromProgram could do this since the recordid wouldn't be available
> > until after the join.
>
> Right. However, Bruce earlier added code to insert the additional
> check after the query to verify on dupchanid and check the chanid's.
> That still doesn't guarantee the right status for programs in the
> past, though. What about "hardcoding" a forced join on chanid, just
> for FromProgram?

That won't work without other changes. In PruneRedundants, PIs for
some chanids can get removed without ever having a corresponding
oldrecorded entry. Consequently, if the FromProgram join always uses
chanid, there won't always be oldrecorded entries for it to match.

A solution for that is to have PruneReduntants call AddHistory (only
for status changes) before deleting a PI. Then all oldrecstatus joins
on oldrecorded could always use chanid. The downside would be an
increase in the number of oldrecorded entries. I don't particularly
like that, but it might be unavoidable.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 6, 2007, 7:54 PM

Post #20 of 35 (4837 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/6/07, David Engel <david [at] istwok> wrote:
> On Mon, Aug 06, 2007 at 06:05:16AM -0500, David Shay wrote:
> > >I'm not sure
> > > PL::FromProgram could do this since the recordid wouldn't be available
> > > until after the join.
> >
> > Right. However, Bruce earlier added code to insert the additional
> > check after the query to verify on dupchanid and check the chanid's.
> > That still doesn't guarantee the right status for programs in the
> > past, though. What about "hardcoding" a forced join on chanid, just
> > for FromProgram?
>
> That won't work without other changes. In PruneRedundants, PIs for
> some chanids can get removed without ever having a corresponding
> oldrecorded entry. Consequently, if the FromProgram join always uses
> chanid, there won't always be oldrecorded entries for it to match.
>
> A solution for that is to have PruneReduntants call AddHistory (only
> for status changes) before deleting a PI. Then all oldrecstatus joins
> on oldrecorded could always use chanid. The downside would be an
> increase in the number of oldrecorded entries. I don't particularly
> like that, but it might be unavoidable.
>

Well, I tried that, or at least what I thought you meant, but I most
have done something terribly wrong. I added a call to AddHistory in
PruneRedunants, right before the second call to delete. That added
entries to oldrecorded for future programs, though, which I don't
think is what was intended. This must need to be qualified more to
work. These records then screwed up the scheduler, and put the whole
thing into a downward spiral...

Argh. Just when I sort of thought I knew what was going on in this
code, I suddenly feel way out of my depth again...

Is the work in FromProgram all in the name of getting accurate
statuses on past programs in the EPG, or is that needed for some other
purpose?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Aug 7, 2007, 7:26 AM

Post #21 of 35 (4822 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On Mon, Aug 06, 2007 at 09:54:08PM -0500, David Shay wrote:
> Well, I tried that, or at least what I thought you meant, but I most
> have done something terribly wrong. I added a call to AddHistory in
> PruneRedunants, right before the second call to delete. That added
> entries to oldrecorded for future programs, though, which I don't
> think is what was intended. This must need to be qualified more to
> work. These records then screwed up the scheduler, and put the whole
> thing into a downward spiral...

Yes, the AddHistory should also be qualified by

nextRecording->recstartts <= schedTime

I would have made the same mistake.

> Is the work in FromProgram all in the name of getting accurate
> statuses on past programs in the EPG, or is that needed for some other
> purpose?

Yes, only to get accurate status. Previously, the scheduler kept a
day's worth of state in memory for past recordings. That worked fine
as long as the scheduler stayed up. If the master backend crash or
was restarted, however, all of that state was lost and the EPG would
display things as if they had never been scheduled.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 7, 2007, 11:56 AM

Post #22 of 35 (4811 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/7/07, David Engel <david [at] istwok> wrote:
> On Mon, Aug 06, 2007 at 09:54:08PM -0500, David Shay wrote:
> > Well, I tried that, or at least what I thought you meant, but I most
> > have done something terribly wrong. I added a call to AddHistory in
> > PruneRedunants, right before the second call to delete. That added
> > entries to oldrecorded for future programs, though, which I don't
> > think is what was intended. This must need to be qualified more to
> > work. These records then screwed up the scheduler, and put the whole
> > thing into a downward spiral...
>
> Yes, the AddHistory should also be qualified by
>
> nextRecording->recstartts <= schedTime

After some more thought, I wondered if maybe the check should be a
call to IsSameTimeslot instead? I'll try some things out tonight.

>
> I would have made the same mistake.
>
> > Is the work in FromProgram all in the name of getting accurate
> > statuses on past programs in the EPG, or is that needed for some other
> > purpose?
>
> Yes, only to get accurate status. Previously, the scheduler kept a
> day's worth of state in memory for past recordings. That worked fine
> as long as the scheduler stayed up. If the master backend crash or
> was restarted, however, all of that state was lost and the EPG would
> display things as if they had never been scheduled.
>

Is that status only used in the EPG, though, or where else might it be
of importance?

> David
> --
> David Engel
> david [at] istwok
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at istwok

Aug 7, 2007, 12:57 PM

Post #23 of 35 (4808 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On Tue, Aug 07, 2007 at 01:56:18PM -0500, David Shay wrote:
> > Yes, the AddHistory should also be qualified by
> >
> > nextRecording->recstartts <= schedTime
>
> After some more thought, I wondered if maybe the check should be a
> call to IsSameTimeslot instead? I'll try some things out tonight.

I don't follow. In PruneRedundants(), any call to AddHistory() must
be qualified by the current time in order to match how it would have
been called in RunScheduler(). IOW, anything in that might happen in
the future is still conjecture at that point. Only after the
scheduler would have acted on something, does it become a mater or
record.

> > Yes, only to get accurate status. Previously, the scheduler kept a
> > day's worth of state in memory for past recordings. That worked fine
> > as long as the scheduler stayed up. If the master backend crash or
> > was restarted, however, all of that state was lost and the EPG would
> > display things as if they had never been scheduled.
>
> Is that status only used in the EPG, though, or where else might it be
> of importance?

Technically, it's important to any user of FromProgram(). It just so
happens the EPG is currently the only user which shows past programs.
All of the other users currently restrict their views to only current
and future programs.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 7, 2007, 4:47 PM

Post #24 of 35 (4812 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/7/07, David Engel <david [at] istwok> wrote:
> On Tue, Aug 07, 2007 at 01:56:18PM -0500, David Shay wrote:
> > > Yes, the AddHistory should also be qualified by
> > >
> > > nextRecording->recstartts <= schedTime
> >
> > After some more thought, I wondered if maybe the check should be a
> > call to IsSameTimeslot instead? I'll try some things out tonight.
>
> I don't follow. In PruneRedundants(), any call to AddHistory() must
> be qualified by the current time in order to match how it would have
> been called in RunScheduler(). IOW, anything in that might happen in
> the future is still conjecture at that point. Only after the
> scheduler would have acted on something, does it become a mater or
> record.
>

Sorry, I wasn't clear. I meant not JUST the check for <= schedtime
but ALSO a check to IsSameTimeslot so that we were only adding the
"precise" "potentially unnecessarily duplicate" entries to
oldrecorded.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


david at shay

Aug 7, 2007, 9:48 PM

Post #25 of 35 (4779 views)
Permalink
Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/7/07, David Shay <david [at] shay> wrote:
> On 8/7/07, David Engel <david [at] istwok> wrote:
> > On Tue, Aug 07, 2007 at 01:56:18PM -0500, David Shay wrote:
> > > > Yes, the AddHistory should also be qualified by
> > > >
> > > > nextRecording->recstartts <= schedTime
> > >
> > > After some more thought, I wondered if maybe the check should be a
> > > call to IsSameTimeslot instead? I'll try some things out tonight.
> >
> > I don't follow. In PruneRedundants(), any call to AddHistory() must
> > be qualified by the current time in order to match how it would have
> > been called in RunScheduler(). IOW, anything in that might happen in
> > the future is still conjecture at that point. Only after the
> > scheduler would have acted on something, does it become a mater or
> > record.
> >
>
> Sorry, I wasn't clear. I meant not JUST the check for <= schedtime
> but ALSO a check to IsSameTimeslot so that we were only adding the
> "precise" "potentially unnecessarily duplicate" entries to
> oldrecorded.
>
Well, never mind about that. That check isn't needed. But, this
doesn't completely solve the problem. Here was a sample case:

1 record rule, any channel, new duplicate rule set to off (normal,
existing behavior)
show matches 3 showings, 2 on one callsign, 1 on a different callsign.
Scheduler detects 1 of the showing on the same callsign as will
record, the other as other showing. The one on the different callsign
is EarlierShowing. So far, so good.
Recording starts. Only 2 entries get added to oldrecorded, the one
for the chanid with the callsign it is really being recorded on
(status -2), and the one with the chanid and the different callsign
(status 4). It should have added the other chanid, but didn't. It
must not have made it through to PruneRedundants at that point, I
guess. (I'll need to add more debug stuff to check why not).

Recording ends. The additional entry gets added to oldrecorded, but
with a status of -3 for recorded, when it should have been 13 for
othershowing. The one that was really recorded also gets set to -3.
I've traced this back, I think, to the fact that when a recording ends
it updates it's status via a call to UpdateRecStatus using a pointer
to *pginfo structure, which then uses IsSameProgramTimeSlot.

Initially, I had further qualified the call here to do the check if
dupchanid was set, then to also check on matching channel ID's. In
this case, the new dupchanid was not in effect, so it just went about
it's merry way iterating through, found 2 matches for the same
callsign via IsSameProgramTimeSlot and updated them both with the
recorded status, incorrectly.

I'm not 100% certain of this, but if the goal is to always add
oldrecorded entries for the past/current stuff, maybe UpdateRecStatus
should just ALWAYS check on a chanid match, just like the join in
FromProgram will now always join on chanid.

Still have to solve the problem of why the initial same callsign/not
recording channel ID didn't get to oldrecorded first, but if it HAD,
then the above logic would work.

Thoughts?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.