mtdean at thirdcontact
Mar 24, 2012, 5:09 PM
Views: 227
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
|
Re: [mythtv-commits] Ticket #10506: threading/timing/logging-problem wath-recordings-screen
