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

[Stefan Brackertz]

yes. It works fine now.

Am 01.04.2012, 01:20 Uhr, schrieb Jim Stichnoth <stichnot at gmail.com>:

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