Mailing List Archive: MythTV: Dev

findid for non-find rules, IsSameProgram checks (help Bruce!)

Index | Next | Previous | View Threaded

david at shay

Aug 1, 2007, 9:39 PM

Post #1 of 7 (666 views)
Permalink

findid for non-find rules, IsSameProgram checks (help Bruce!)

Bruce,

In doing work on the chanid duplication detection, I came across
something that doesn't seem right that perhaps you can clarify.
Somewhere along the way (I think around changeset 7429?), findid
started to get populated for all rules, not just find rules. It looks
like with some date value based on the start date of the recording.

So, I recently set up 3 recordings in a test. 2 of those were for the
same show on different chanid's, 1 was for a different show
altogether. All 3, however, had the same findid, I believe because
they have the same startdate.

All of that is fine (maybe?), but then in IsSameProgram, I think there
might be a problem. There are 3 checks, then a check for title. If
it makes it past this logic, as long as the findid's match,
IsSameProgram return's true (line 1393 of programinfo.cpp). This is
before it does any duplicate checking based on subtitle, etc. This
just doesn't seem right to me. It would seem that two programs with
different subtitles but the same findid would return true to
IsSameProgram.

Should this findid check be limited to certain find rules? Am I
missing something in this analysis?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at shay

Aug 1, 2007, 10:15 PM

Post #2 of 7 (643 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On 8/1/07, David Shay <david [at] shay> wrote:
> Bruce,
>
> In doing work on the chanid duplication detection, I came across
> something that doesn't seem right that perhaps you can clarify.
> Somewhere along the way (I think around changeset 7429?), findid
> started to get populated for all rules, not just find rules. It looks
> like with some date value based on the start date of the recording.
>
> So, I recently set up 3 recordings in a test. 2 of those were for the
> same show on different chanid's, 1 was for a different show
> altogether. All 3, however, had the same findid, I believe because
> they have the same startdate.
>
> All of that is fine (maybe?), but then in IsSameProgram, I think there
> might be a problem. There are 3 checks, then a check for title. If
> it makes it past this logic, as long as the findid's match,
> IsSameProgram return's true (line 1393 of programinfo.cpp). This is
> before it does any duplicate checking based on subtitle, etc. This
> just doesn't seem right to me. It would seem that two programs with
> different subtitles but the same findid would return true to
> IsSameProgram.
>
> Should this findid check be limited to certain find rules? Am I
> missing something in this analysis?
>
Sorry to answer my own post, but let me make sure I have this right.
Further debugging revealed that at least when being called by the
scheduler, for "normal" non-find rules, the value within the function
was always "0" for findid. This seems to trace back to the SQL Case
statement in the BUSQ in scheduler.cpp, where if it's not
findone,findweekly, finddaily, or override, then it sets findid to 0
regardless of what's in the record table. Is that right?

Also, further work on the chanid duplicate detection seems to have
revealed that I don't even have to touch the BUSQ, as long as I put
the appropriate detection in IsSameProgram. That actually seems to
make this A Whole Lot Easier than I thought it might be. In fact, I
think I've got it about 80% working.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 2, 2007, 7:44 AM

Post #3 of 7 (629 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On Wed, Aug 01, 2007 at 11:39:43PM -0500, David Shay wrote:
> All of that is fine (maybe?), but then in IsSameProgram, I think there
> might be a problem. There are 3 checks, then a check for title. If
> it makes it past this logic, as long as the findid's match,
> IsSameProgram return's true (line 1393 of programinfo.cpp). This is
> before it does any duplicate checking based on subtitle, etc. This
> just doesn't seem right to me. It would seem that two programs with
> different subtitles but the same findid would return true to
> IsSameProgram.

It's a bug. I have a patch lying around somewhere to address this
problem. It sets the parentid equal to the recordid in the scheduler
if it's not already set. The findid check can then be qualified by
parentid != 0 and parentid == other.parentid. This change also
simplifies some other code which conditionally uses parentid or
recordid -- it can unconditionally use parentid.

I wasn't sure of the full implications of the change, mainly on
mythweb so I set it aside and haven't gotten back to it yet.

On Thu, Aug 02, 2007 at 12:15:04AM -0500, David Shay wrote:
> Also, further work on the chanid duplicate detection seems to have
> revealed that I don't even have to touch the BUSQ, as long as I put
> the appropriate detection in IsSameProgram. That actually seems to
> make this A Whole Lot Easier than I thought it might be. In fact, I
> think I've got it about 80% working.

Are you sure about that? I believe changing IsSameProgram will handle
the case where both recordings can be done at the same time. I'm not
sure it will if conflicts force one to a later time. In that case, I
think the presence of the earlier recording in the oldrecorded or
recorded table will result in the latter being treated as a duplicate.

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 istwok

Aug 2, 2007, 8:47 AM

Post #4 of 7 (636 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On Thu, Aug 02, 2007 at 09:44:53AM -0500, David Engel wrote:
> It's a bug. I have a patch lying around somewhere to address this
> problem. It sets the parentid equal to the recordid in the scheduler
> if it's not already set. The findid check can then be qualified by

I just went back and reviewed my old patch. I believe the findid
check you were referring to is completely bogus. There is another,
more qualified, findid check above there that should be sufficient.

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 2, 2007, 7:14 PM

Post #5 of 7 (619 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On 8/2/07, David Engel <david [at] istwok> wrote:
> On Wed, Aug 01, 2007 at 11:39:43PM -0500, David Shay wrote:
> > All of that is fine (maybe?), but then in IsSameProgram, I think there
> > might be a problem. There are 3 checks, then a check for title. If
> > it makes it past this logic, as long as the findid's match,
> > IsSameProgram return's true (line 1393 of programinfo.cpp). This is
> > before it does any duplicate checking based on subtitle, etc. This
> > just doesn't seem right to me. It would seem that two programs with
> > different subtitles but the same findid would return true to
> > IsSameProgram.
>
> It's a bug. I have a patch lying around somewhere to address this
> problem. It sets the parentid equal to the recordid in the scheduler
> if it's not already set. The findid check can then be qualified by
> parentid != 0 and parentid == other.parentid. This change also
> simplifies some other code which conditionally uses parentid or
> recordid -- it can unconditionally use parentid.
>
> I wasn't sure of the full implications of the change, mainly on
> mythweb so I set it aside and haven't gotten back to it yet.
>
> On Thu, Aug 02, 2007 at 12:15:04AM -0500, David Shay wrote:
> > Also, further work on the chanid duplicate detection seems to have
> > revealed that I don't even have to touch the BUSQ, as long as I put
> > the appropriate detection in IsSameProgram. That actually seems to
> > make this A Whole Lot Easier than I thought it might be. In fact, I
> > think I've got it about 80% working.
>
> Are you sure about that? I believe changing IsSameProgram will handle
> the case where both recordings can be done at the same time. I'm not
> sure it will if conflicts force one to a later time. In that case, I
> think the presence of the earlier recording in the oldrecorded or
> recorded table will result in the latter being treated as a duplicate.

No, I wasn't sure about it. That was the next case, which, following
every normal 80-20 rule, will take the next 80% of the work, since you
are correct, IsSameProgram only solves half the battle. It's pretty
obvious why, now that I look at it, since I think the query just
matches on programid automatically. Oh well, I thought going into
this that I'd have to do something to that query....
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at shay

Aug 2, 2007, 7:18 PM

Post #6 of 7 (621 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On 8/2/07, David Engel <david [at] istwok> wrote:
> On Thu, Aug 02, 2007 at 09:44:53AM -0500, David Engel wrote:
> > It's a bug. I have a patch lying around somewhere to address this
> > problem. It sets the parentid equal to the recordid in the scheduler
> > if it's not already set. The findid check can then be qualified by
>
> I just went back and reviewed my old patch. I believe the findid
> check you were referring to is completely bogus. There is another,
> more qualified, findid check above there that should be sufficient.
>

OK. I'll remove it in my update. I still wonder if the check above
that ought to be even more qualified by the specific findtypes and
override types. It looks like IsSameProgram is most often called by
the scheduler, which defaults in a 0 for findid for those types, but
that is not always true for other cases where it can also be called
from.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 4, 2007, 10:06 AM

Post #7 of 7 (607 views)
Permalink

Re: findid for non-find rules, IsSameProgram checks (help Bruce!) [In reply to]

On Thu, Aug 02, 2007 at 09:18:06PM -0500, David Shay wrote:
> OK. I'll remove it in my update. I still wonder if the check above
> that ought to be even more qualified by the specific findtypes and
> override types. It looks like IsSameProgram is most often called by
> the scheduler, which defaults in a 0 for findid for those types, but
> that is not always true for other cases where it can also be called
> from.

There might be a very subtle bug when overrides are used with find
rules. I don't remember for sure from my earlier testing since it's
been a while. Otherwise, the check should be sufficient for all other
cases since findid is not set for rules where it doesn't apply. If it
is, it's a bug and please let me know.

On Thu, Aug 02, 2007 at 09:14:27PM -0500, David Shay wrote:
> No, I wasn't sure about it. That was the next case, which, following
> every normal 80-20 rule, will take the next 80% of the work, since you
> are correct, IsSameProgram only solves half the battle. It's pretty
> obvious why, now that I look at it, since I think the query just
> matches on programid automatically. Oh well, I thought going into
> this that I'd have to do something to that query....

There's a potential scheduler optimization I've been wanting to try.
It might prove useful for your task.

Currently, the scheduler checks duplicates for all matching programs
in a single query. That means the join conditions for oldrecorded and
recorded have to account for all of the supported duplicate check
methods. MySQL is not efficient with those joins, particularly the
oldrecorded one, and causes them to be the biggest factor in how long
the scheduler query takes.

What I'd like to try is have the scheduler run a separate query for
each recordid with matching programs. The join conditions could then
be tailored for each recordid and, in theory, be simpler and more
efficient. For example, single, override and no duplicate rules wouldn't
need any duplicate checking at all. Manual rules would only need to
check the subtitle (where the date and time is place). If programids
are available, most other rules could get by only checking those.

Running multiple queries would certainly add some overhead, but it
just might be offset by the efficiency of running more targeted duplicate
checks.

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads