[mythtv] [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen

Jim Stichnoth stichnot at gmail.com
Sat Mar 31 23:20:05 UTC 2012


On Sat, Mar 24, 2012 at 5:09 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> This sounds like:
>
> http://www.gossamer-threads.com/lists/mythtv/users/508829#508829
> +
> http://www.gossamer-threads.com/lists/mythtv/users/508860#508860
> +
> http://www.gossamer-threads.com/lists/mythtv/users/508928#508928
> (where the 3rd says to do the "Change Group Filter" to see if it's
> slow--and yours is).
>
> Please try changing your DateFormat as specified in the 2nd post and see
> if it changes the timing.

A more likely explanation has emerged.  In 0.24, and in 0.25beta+RC,
there is a bug in the mytharchive plugin, in which the DB Settings
cache is accidentally not reenabled after the schema check.  If
mytharchive is the last plugin loaded, then the DB Settings cache
remains disabled until some other action enables it, such as going
through the Appearances setup screens.  Among other things, this
causes several DB accesses for every item when loading the Watch
Recordings screen.

This is currently a problem in 0.24, but thanks to some refactoring in
0.25, it happens much more.  By my not-necessarily-accurate count,
0.24 has 3 Settings lookups per item, whereas 0.25RC has about 24
Settings lookups per item.  Again, this is only a problem when
mytharchive is the last plugin loaded.  The order of loading plugins
is unspecified -- it is up to the Qt implementation.

The mytharchive bug has been fixed, and hopefully that will prove to
be the source of the observed Watch Recordings slowdown.

-- Jim


More information about the mythtv-dev mailing list