Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#10506 closed Bug Report - General (Duplicate)

threading/timing/logging-problem wath-recordings-screen

Reported by: t.brackertz@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: Unspecified
Severity: medium Keywords:
Cc: Ticket locked: no


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.

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

Change History (3)

comment:1 Changed 9 years ago by beirdo

Without a lot of supporting information, this is getting closed as "Works for me".

The logging is nearly completely asynchronous to all the other threads (short of a very short time where it has a lock protecting the queue). You would have to show conclusively that that this the logging. Maybe use gdb to get a backtrace during the delay periods.

Also, without the logs in question, and a good description of what you are doing at the time, there's nothing we can do.

Please report bugs, not your suppositions as to what's to blame. That is likely to send us off on a wild goose chase, and make it that much harder to find the true issue.

comment:2 Changed 9 years ago by Jim Stichnoth

Resolution: Duplicate
Status: newclosed

This is essentially a duplicate of #10161. Logging is unrelated. The only mystery is why some configurations take so long to generate the strings (particularly date/time strings) for each ProgramInfo? object.

FYI, the UI freezes up (no clock update, no window refresh) because the expensive initialization is being done within the event loop without yielding.

comment:3 Changed 9 years ago by t.brackertz@…

Note: See TracTickets for help on using tickets.