Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#10740 closed Patch - Bug Fix (Fixed)

[PATCH] libmythui: Fix an assert failure in Qt when playing a video

Reported by: Lawrence Rust <lvr@…> Owned by: Jim Stichnoth
Priority: minor Milestone: 0.25.1
Component: MythTV - Video Playback Version: 0.25-fixes
Severity: medium Keywords: DVD assert
Cc: Ticket locked: no

Description

Trying to play a DVD with a debug build of the Qt library results in this assertion failure: ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread a8625e78. Receiver 'aa_OSD_SUBTITLES' (of type 'MythScreenType?') was created in thread 9890750", file kernel/qcoreapplication.cpp, line 349

Backtrace & patch attached

Attachments (2)

video-backtrace.txt (4.5 KB) - added by Lawrence Rust <lvr@…> 12 years ago.
0001-libmythui-Fix-an-assert-failure-in-Qt-when-playing-a.patch (1.2 KB) - added by Lawrence Rust <lvr@…> 12 years ago.

Download all attachments as: .zip

Change History (13)

Changed 12 years ago by Lawrence Rust <lvr@…>

Attachment: video-backtrace.txt added

Changed 12 years ago by Lawrence Rust <lvr@…>

comment:1 Changed 12 years ago by danielk

Component: MythTV - Video PlaybackMythTV - Captions
Owner: set to Jim Stichnoth
Status: newassigned

comment:2 Changed 12 years ago by danielk

Jim, this is a real issue but Lawrence's patch fixes a side effect and not the root cause. The problem is that MythUI objects need to be owned by and for the most part interacted with only in the main UI thread.

In this case the objects are probably created in the decoder thread. They either need to be created in the UI thread or re-parented to the UI thread when the decoder passes them along to the UI thread for rendering. Using deleteLater() here might just trade an ASSERT for a memory leak, if the thread that created the objects isn't running a Qt event loop.

comment:3 Changed 12 years ago by Jim Stichnoth

Milestone: unknown0.25.1
Status: assignedaccepted

In this case, the MythUI objects are actually created in the UI thread, but the decoder is trying to clear/delete them. This makes me realize there is a race condition here that needs to be addressed in the SubtitleScreen? class, which as a side effect will let us avoid the more invasive change to MythUIType.

comment:4 Changed 12 years ago by Jim Stichnoth <jstichnoth@…>

In f0f37a55d67ffffa27d51ebc6b2cb48589c820fc/mythtv:

Subtitles: Avoid changing subtitle state in the decoder thread.

Use the proper API to defer subtitle changes to the UI event loop, to
avoid creating or deleting MythUI objects in a non-UI thread.
Refs #10740

comment:5 Changed 12 years ago by Jim Stichnoth <jstichnoth@…>

In b695979eb834dfc64b31b8273424104e1e2d48d9/mythtv:

Subtitles: Avoid changing subtitle state in the decoder thread.

Use the proper API to defer subtitle changes to the UI event loop, to
avoid creating or deleting MythUI objects in a non-UI thread.
Refs #10740
(cherry picked from commit f0f37a55d67ffffa27d51ebc6b2cb48589c820fc)

comment:6 Changed 12 years ago by Jim Stichnoth

Component: MythTV - CaptionsMythTV - Video Playback
Resolution: Fixed
Status: acceptedclosed

Lawrence, I believe this should be fixed, but I don't have a good way to test it, so I'd appreciate it if you could retest and reopen the ticket if you see the same problem.

Fundamentally, this turned out to be a video playback problem, rather than MythUI or captions.

comment:7 Changed 12 years ago by Lawrence Rust <lvr@…>

Confirm fixed in commit b695979.

NB I would strongly recommend testing with a debug build of Qt (and many of the other libraries used by Myth) as they check & report warnings and errors for many API calls. It's very easy to build MythTV with a debug Qt by using my mythbuild.sh script from mythpackaging or here: http://www.softsystem.co.uk/download/mythtv/mythbuild.sh. Once you've got the script then run it:

mythbuild.sh -H -d -b master

-H :build for the host (default is xcompile to win32)
-d : Debug build
-b : Select mythtv branch

It will automatically download all the lib sources required.

If you want to use an existing mythtv git repo then cd to the parent of the repo and mv or ln -s the repo to mythtv and run mythbuild.sh from that directory - it will use the currently checked out branch.

comment:8 Changed 10 years ago by Jim Stichnoth <jstichnoth@…>

In 438d29a4a64b38ac239f61208262e35a3e486d91/mythtv:

Subtitles: Avoid changing subtitle state in the decoder thread.

This addresses the clearing of stale subtitles after a seek.
Refs #10740.

comment:9 Changed 9 years ago by Jim Stichnoth <jstichnoth@…>

In ac3a988f2e9140322b1a15c34d6ac87071c69d7e/mythtv:

Subtitles: Fix automatic display of captions/subtitles.

There was something of a race condition in the previous code. At
startup of playback, the decoder thread runs ahead and updates track
lists as it encounters them, including audio, cc608, cc708, etc. If
no subtitle tracks are found before the UI thread gets to a certain
point, the UI thread commits to keeping subtitles disabled, regardless
of the "automatically display subtitles" setting.

In the new version, at startup of playback, the UI thread keeps the
original intention alive so that subtitles will automatically start
displaying when they eventually arrive.

Note that this fix doesn't address the problem where the player ought
to switch to a "better" subtitle track type when it comes along, such
as switching from cc608 to cc708.

Refs #10740 (only because this fixes a fix with that ref)

comment:10 Changed 9 years ago by Jim Stichnoth <jstichnoth@…>

In 483f8dd5674acd127bcf342900ea18230b9c2ce3/mythtv:

Subtitles: Avoid changing subtitle state in the decoder thread.

This addresses the clearing of stale subtitles after a seek.
Refs #10740.

(cherry picked from commit 438d29a4a64b38ac239f61208262e35a3e486d91)

comment:11 Changed 9 years ago by Jim Stichnoth <jstichnoth@…>

In bcf888fdd4034997c2f2a5d0d877da0e1f463c2e/mythtv:

Subtitles: Fix automatic display of captions/subtitles.

There was something of a race condition in the previous code. At
startup of playback, the decoder thread runs ahead and updates track
lists as it encounters them, including audio, cc608, cc708, etc. If
no subtitle tracks are found before the UI thread gets to a certain
point, the UI thread commits to keeping subtitles disabled, regardless
of the "automatically display subtitles" setting.

In the new version, at startup of playback, the UI thread keeps the
original intention alive so that subtitles will automatically start
displaying when they eventually arrive.

Note that this fix doesn't address the problem where the player ought
to switch to a "better" subtitle track type when it comes along, such
as switching from cc608 to cc708.

Refs #10740 (only because this fixes a fix with that ref)

(cherry picked from commit ac3a988f2e9140322b1a15c34d6ac87071c69d7e)

Note: See TracTickets for help on using tickets.