t.brackertz at gmx
Apr 2, 2012, 1:00 PM
Post #3 of 3
yes. It works fine now.
Re: [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen
[In reply to]
Am 01.04.2012, 01:20 Uhr, schrieb Jim Stichnoth <stichnot [at] gmail>:
> On Sat, Mar 24, 2012 at 5:09 PM, Michael T. Dean
> <mtdean [at] thirdcontact> wrote:
>> This sounds like:
>> (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
mythtv-dev mailing list
mythtv-dev [at] mythtv