Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

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

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


mtdean at thirdcontact

Mar 24, 2012, 5:09 PM

Post #1 of 3 (303 views)
Permalink
Re: [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen

On 03/24/2012 07:15 PM, MythTV wrote:
> #10506: threading/timing/logging-problem wath-recordings-screen
> ---------------------------------+--------------------------------------
> Reporter: t.brackertz@… | Type: Bug Report - General
> Status: new | Priority: minor
> Milestone: unknown | Component: MythTV - General
> Version: Unspecified | Severity: medium
> Keywords: | Ticket locked: 0
> ---------------------------------+--------------------------------------
> With 0.24 there had been no noticeable delays at all when playing in the
> wath recordings screen. (Core i3, about 4000 recordings)
> Since I updated to 0.25 there are delays everytime I change the recording
> group (and when entering the watch recordings screen):
>
> Changing the recording group takes about 1 second per 100 recordings in
> the group I change into. During this time mythfrontend seems to be dead.
>
> When entering the watch recordings screen the clock is runnning for a very
> short time then it stops for about 40s before I see the all recordings
> group.
>
> There are no logging entries.
>
> I suppose this is a threading/timing problem with the new logging: One
> thread waits for another one until cathed by a timeout because of the
> following observations:
>
> 1.
> Sometimes (very rare) there is no delay at all
>
> 2.
> Sometimes there is a much longer delay (minutes)
>
> 3.
> Sometimes there is a delay after deleting a record.
>
> 4.
> When entering wath-recordings-screen the harddisks work and the mouse
> pointer reacts during the very short time the clock is running. Sometimes
> there is some logging (which doesn't belong to the recordings screen but
> something like housekeeping, start of a recording and so on.). In the
> second (long) part of the waiting time the screen isn't updated any
> longer. This means one can see the stopped clock and no mouse pointer.
> When jumping to another window and then back to mythfrontend there is only
> the background of the theme. I have never observed any logging during this
> period, either, but many logging entries at the same time when the delay
> is over.
>
> During this time mythbackend (despite logging) works normal: Recordings
> and jobs go on as usual.
>
> The problem doesn't exist in mytharchive's choose-recordings-screen.

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.

> Maybe the UI thread is waiting for the logging thread?
>
> ---------------
> There is a similar problem with mythtv-setup which may have a similar
> reason:
>
> - Choose a video source.
> - Logging says:
> {{{
> Locking input devices
> XMLTVConfig::Load: Running 'tv_find_grabbers baseline'.
> }}}
>
> - screen is not updated for 26 seconds and no logging entries during this
> time
> - screen shows properties of video source and the following logging-
> entries appear:
> {{{
> Child PID 15543 killed with Beendet
> XMLTVConfig::Load: Failed to run tv_find_grabbers
> Unlocking input devices
> }}}
>

That is because mythtv-setup runs the external command
"tv_find_grabbers" and it takes so long to run on your system that
mythtv-setup eventually gives up after its 25s timeout (i.e. your XMLTV
install/configuration is broken).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


stichnot at gmail

Mar 31, 2012, 4:20 PM

Post #2 of 3 (262 views)
Permalink
Re: [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen [In reply to]

On Sat, Mar 24, 2012 at 5:09 PM, Michael T. Dean
<mtdean [at] thirdcontact> 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
http://www.mythtv.org/mailman/listinfo/mythtv-dev


t.brackertz at gmx

Apr 2, 2012, 1:00 PM

Post #3 of 3 (248 views)
Permalink
Re: [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen [In reply to]

yes. It works fine now.

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


_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.