[mythtv] On the FindOne recordings, conflict resolution

Bruce Markey bjm at lvcm.com
Thu Jan 20 14:42:57 EST 2005


Other than the specifics of what is required in the fields of
the 'record' table, many of your questions are covered in
http://www.mythtv.org/docs/mythtv-HOWTO-11.html#ss11.6 .

Brad Templeton wrote:
> On Wed, Jan 19, 2005 at 10:26:28PM -0600, David Engel wrote:
> 
>>>    Is this the expected behaviour?
>>
>>Yes.  As I noted before, priorities are still used to decide what and
>>when to record.  The way I set things up is like this.  I give
>>positive priorities to all of the recurring programs that I really
>>want to record.  I give negative priorities to all of the recurring,
>>"filler" stuff I'd like to record but don't care if it gets missed or
>>records later.  Then, all of the "off-the-cuff" single and find
>>records I create get the default, zero priority right in the middle
>>where I want them.
> 
> 
> Hmm.  I would have expressed the ultimate goal of priorities as follows:
> 
>     "Try to record as many of the requested shows as you can.  If 2 or
>     more must conflict (ie. you can't fix it by moving either one of
>     them) then record the show of higher priority."
> 
> You are saying, if I read you right, that the higher priority for the
> series beats out the lower priority movie, even though the problem
> could be solved by recording the series later that night?

As Isaac pointed out, the Reschedule Higher Priorities option
in the Recording Priorities settings is for situations like this.
David believes that it is best to get the higher priority show
as the listing may change and you might miss out on recording
the higher priority show but he included schedMoveHigher as an
option.  I believe it is best to use SMH and if you see Iron Chef
marked as "L"ater, you can still choose "Record anyway" if you
decide you'd rather have the earlier showing than the movie.

> Note that doing what I describe above as the right thing is computationally
> complex, possibly non-polynomial, but constrainable and usually over a
> small set.

The scheduler first places everything by the priority rules
described in the docs. If SMH is true, it makes another pass
for the items that resulted in a "C"onflict. It then looks to
see if any of the overlapping shows could move. If the move
results in a conflict, it does not recurse but sticks with the
original conflict.

>>60 seconds is unusually long.  What hardware are you using?  Perhaps
>>there is something wrong with your database.
> 
> 
> Athlon-3000, the database seems fine.  My guess is it might be the
> use of LIKE %string% 150 times.  I will test that.

I think the problem here is that you see these titles as something
you are searching for. However, title search rules mean that
you are trying to find a sub-string in the titles but you actually
have the full titles. If you have the full titles you should default
to search=0 and do a normal lookup. Not only is LIKE %string%
unnecessarily slow but search rules create a separate query for
each of these exceptional WHERE clauses. If you use a normal
title lookup, they are simply joined in The Ugly Query and are
all found in a single request.

>>FindOne is primarily intended for movies and specials, IOW not series.
>>To find a specific episode of a series, you should use a search
>>record.

FindOne pre-dates having programids and still needs to work for
grabbers that do not have programids. Some of the problems that
I saw when I was working on this were specials with "(Live)" vs
"(Taped)" and movies the "(Stereo)" vs "(Dolby)" plus the problems
of blank subtitles and/or blank descriptions. Therefore, it
deliberately ignores descriptive differences and only matches
titles in order to behave correctly for the intended use.

> As noted that is failing CPU-wise.  I just did a test using LIKE %string%
> and it took about 25 seconds in my program, so that's probably the culprit.

Try it with type=6 search=0 so that it includes them in TUQ as
program.title = 'string'. That should be faster but you probably
would be better off keeping your titles in a text file, doing
a query against the mythconverg.program table then only interjecting
the titles that are known to be in the current listings.

>>See above.  FWIW, SingleRecord doesn't really do what you are asking
>>for either.  All it really does is record that title at that time.
>>The network could change the episode and Myth would still record it.
> 
> 
> Right, so I would need to code (once I can get mythtv to link, sigh)
> a new kind of query that is a mix between the FindOne and the SingleRecord.
> 
> Or presumably something that is identical to FindOne but keys off the
> ProgramID or Title/Subtitle rather than just the Title would do just
> the job I am looking for.

This is where search rules are needed. If you have a subtitle,
of phrase in the description, search for that phrase. FindOne
will select one from the results returned. I often do this for
a specific episode of A&E's Biography or The E! True Hollywood
Story.

> Might also propose a change of the vocabulary to make things clearer,
> since you come to a recording by picking an episode rather than a series
> in the UI, the phrase "One showing of this program" is ambiguous and
> might be clearer as "One showing of this Title" or "Of this series" if
> there is a SeriesID, and "Of this program" if there is not.

It's already been changed from "program" to "title". 

> I presume FindOne was intended to allow you to say "Hmm, there's a new
> series, grab an episode of it, any episode!"   I must say I was confused

I do this all the time. From the New Titles page I'll FindOne on
a new series. I've never seen it so I just want a sample and any
episode will do. This is a behavior that you can't get with the
traditional rules. If it did try to match an exact episode and it
was the last showing and there was a conflict, the rule would be
stuck waiting for that exact episode to show up again.

> by it, in that if you pick a specific episode off the menu and ask
> to record it, it is surprising to see it record a different one and
> not the one you clicked on.

If there is episode info then the user has the option of using a
normal recurring types to match episodes. The intent of FindOne
is to choose a showing for titles where all the showings should
be the same thing. With descriptions, a Channel rule could be
set and removed afterwards. If there are other episodes ahead
of the target they can be marked "Never record". Another approach
is to use a search rule that matches just the one episode and record
one showing.

The Find type rules offer an alternative approach that can be
useful in situations where trying to match descriptive information
will not do the right thing. This will become more obvious with the
new FindDaily and FindWeekly that went in yesterday. It's a positive
that these behave differently and that you can choose whichever
approach better suits the need.

> d)  My own tests of doing 200 queries for Movies in the program table
>     returns almost immediately.  However, I am using a somewhat
>     smarter query of "title LIKE 'moviename' AND category_type = 'movie'

"LIKE" not "="? And wouldn't it be more efficient to check the
category_type before the title (thought it may optimize to do
this anyway).

SearchType 1 allows embedding actual SQL which will go into the
WHERE clause of the query. In current CVS, (maybe you should have
a friend compile it for you) this is exposed in two places.
Advanced search has a popup that allows you to choose attributes
for six common fields and stores the search for future reuse.
Custom Record exposes a text box to directly edit any arbitrary
SQL to include in a customized search rule. Among the examples are
a rule to record every sci-fi movie with two star or less from before
1970 and a rule to record any NBA games that involve any of the teams
included in a list. The kPowerSearch rules can be injected with
whatever clauses are needed.

--  bjm


More information about the mythtv-dev mailing list