[mythtv] On the FindOne recordings, conflict resolution

Brad Templeton brad+mydev at templetons.com
Thu Jan 20 20:51:46 EST 2005


On Thu, Jan 20, 2005 at 01:51:46PM -0800, Bruce Markey wrote:
> Brad Templeton wrote:
> But you need a compiled and linked version to see and use the
> current features regardless of how you obtain those binaries.
> What I didn't mention is that there was a bug for kPowerSearch
> that would prevent these rules from working in 16.0. You would
> need current, or at least post Oct 19th CVS to take advantage of
> kPowerSearch rules. There have been several other things that
> have been added or tweaked that relate to your questions such
> as the text has been changed from "program" to "title" and the
> scheduling docs have been updated. Most importantly, there was
> a fix that sped up scheduler times significantly on Oct 30. See:
> 
> http://cvs.mythtv.org/cgi-bin/viewcvs.cgi/mythtv/programs/mythbackend/scheduler.cpp
> 

Thanks, and I apologize, I had intended that to be a private message
not one to the list.   I do appreciate genuine efforts to help.

I looked over the kPowerSearch code in the cvs repository, which
still uses LIKE %string% for title/sub/desc, though it is going to
be more efficient because of the ability to limit by category_type to
movies, for example.   However, as noted, a test of doing 250 LIKE %%
scans even with the qualifiers still took about 25 seconds on a well
powered machine, while the scan without %% returns almost immediately
as desired.

I could change the powersearch to offer searches without %%.  It looks
like it would allow a raw SQL query (with a warning written to the logs?)
which could do the job.

But I now feel that filling the "record" table with hundreds of queries
is not the right approach for what I'm implementing, even if I did
make it efficient.   (Also, I forsee it containing even a thousand
queries if we start getting into my concept of watching 'only the best'
of a series.  In this case, you get a list prepared by fans of the
best N% of the episodes of a series that's in reruns.  You add this
list, and thus watch the series with no bad episodes.  You read on the
web what happened in the bad episodes -- life is too short to watch
bad TV.   I have already watched 2 different series this way, and it
is great -- but I did it manually, either individual scheduling each
recording, or manually deleting the turkey episodes after the fact.)

You don't really want to re-run all the wishlist searches every time an
adjustment is made to the recording table, I think, nor do you want
them cluttering the UI, so it is best to put them in their own table
or other location, the queries to be run less frequently, and in the
background.   Right now myth is not prepared for the queries to take
a long time, and it actually goes away to the point that the frontend
reports the backend is down.   (That could probably be fixed with some
thread rearrangement, though.)

The idea of putting in the critic concept cemented this, it's better as
an external task, though eventually run by the myth scheduler so you
don't have to play with the cron.

Thanks for the help.  If somebody else doesn't, I will put together what
looks like what should be a fairly simple patch for a show specific
record request which does what I would expect from FindOneRecord, though
it need not be in the UI (making it even simpler) -- though frankly my
proposal would be to just replace FindOneRecord with these semantics but
as noted, some people do use it as a "grab anything of this series just
once"  (Which could also be done with title search of course.)



More information about the mythtv-dev mailing list