[mythtv-commits] Ticket #9223: Sluggish menu when watching a recording

[MythTV]

#9223: Sluggish menu when watching a recording
-------------------------------------+--------------------------------
 Reporter:  glemsom@…                |          Owner:  markk
     Type:  defect                   |         Status:  infoneeded_new
 Priority:  minor                    |      Milestone:  0.24.1
Component:  MythTV - Video Playback  |        Version:  0.24-fixes
 Severity:  medium                   |     Resolution:
 Keywords:  sluggish menu            |  Ticket locked:  0
-------------------------------------+--------------------------------

Comment (by markk):

 Replying to [comment:29 dgatwood@…]:
 > Ah.  Looks like I was too quick to assume that this was the same issue
 as in the later builds.  Now that I've rolled back to the November build,
 I'm seeing the horribly sluggish menu performance.  With the January
 build, playback system is completely uncontrollable.  These might or might
 not be related issues.

 I'm pretty sure it's the same issue, just manifesting itself in a slightly
 different way (or more/less extreme at least).

 Anyway, thanks for your comments. They've helped clarify my own thoughts
 and have largely confirmed my suspicions. Unfortunately there probably is
 no easy and or quick fix.

 With the OSD re-write (that went into the 0.24 release), the threading
 model for video playback was changed. Previously there were separate
 threads for both video playback and decoding. With the OSD using
 libmythui, and hence QWidgets, it needed to operate within the main thread
 and hence the extra video playback thread was removed (it also prevented
 some nasty X related crashes).

 It's fair to say we're still picking out some of the unexpected side
 effects of that change.

 There are still various actions that can and do block for too long but in
 terms of steady state video playback without user interaction, there are 2
 areas that will obviously block for significant periods - deinterlacing
 and video sync.

 The effects of deinterlacing are easy enough to eliminate for test
 purposes by disabling deinterlacing :)

 Video sync is trickier but a quick hack into
 BusyWaitVideoSync::WaitForFrame and breaking out the usleep into smaller
 chunks with a call to qApp->processEvents() (or indeed some form of loop
 with qApp->processEvents() and a continuous check of CalcDelay()) would
 probably be interesting/informative.

 FYI, when video is being played, the main loop is in tv_play.cpp, line
 298. Essentially that processes application events and then prepares and
 displays one frame.

 There are other quicker fixes that can probably go in around keypress
 handling in the TV class but I'm quite sure they're not the root cause
 here.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9223#comment:30>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center