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