[mythtv-commits] Ticket #12902: Cannot make QOpenGLContext current in a different thread (occurred while watching live tv)

MythTV noreply at mythtv.org
Thu Jan 26 12:29:34 UTC 2017


#12902: Cannot make QOpenGLContext current in a different thread (occurred while
watching live tv)
-------------------------------------------------+-------------------------
 Reporter:  William L. DeRieux IV                |          Owner:
  <WilliamDeRieux@…>                             |
     Type:  Bug Report - Crash                   |         Status:  new
 Priority:  critical                             |      Milestone:  0.28.1
Component:  Qt5 issues                           |        Version:  0.28.0
 Severity:  high                                 |     Resolution:
 Keywords:                                       |  Ticket locked:  0
-------------------------------------------------+-------------------------

Comment (by rsiddons):

 The stack trace suggests that playback was not 1x speed at the time.

 I can't test atm but I suspect a quick fix is to revert 7b4402def.
 It's not wholly wrong but exposes deeper issues within the player code.

 IMO:

 Prior to 2010 !ChangeSpeed() was only used by UI thread as a "handle
 effects of changing speed" and safely called rendering.

 59f10b398 caused it to be called from decoder thread (by
 !FileChangedCallback). That appears to be mainly due to changing !LiveTv
 programme ("new programme so reset everything").

 That seemed ok because:
 1. If previous programme couldn't support a 2x deinterlacer then then it's
 unlikely the new one will, so !BestDeint() will never be invoked by
 decoder thread.
 2. Prior to 7b4402def, if playback is not 1x speed then we cannot be
 currently using a 2x deinterlacer, so !FallbackDeint() will never be
 invoked by decoder thread.

 I suspect the issue will only occur when using 2x deinterlacer & playback
 is not 1x. Changing speed via UI will never invoke it directly (UI thread
 does the work). However a subsequent decoder event will.
 !LiveTv programme transition will probably trigger it. If a video is
 triggering it then something else is also causing the decoder to reset.

 The underlying issue is that the decoder thread should be signalling the
 UI thread to effect the deinterlacer change.

 Maybe !FileChangedCallback should somehow get the UI to invoke
 !ChangeSpeed() ? It's not clear whether that would cause other issues.

 Changing the !FallbackDeint() condition to be the same as 7b4402def should
 work also. Note that the !ChangeSpeed() code is almost a cut/paste of
 !ForceDeinterlacer(). That would restore the previous "hopefully this will
 never get invoked by wrong thread" situation. Some comments would be nice!
 Although ugly, an explicit thread-check here is warranted to signal the
 underlying dodginess.

 Disallowing user selection of 2x interlacers when playback is not 1x
 simply avoids the problem arising. Arguably it is the same solution by a
 different (more opaque) means.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/12902#comment:16>
MythTV <http://www.mythtv.org>
MythTV Media Center


More information about the mythtv-commits mailing list