Opened 16 years ago
Closed 16 years ago
#4320 closed defect (fixed)
Frontend lockups (Windows) due to threading issues (refs #4085)
Reported by: | Owned by: | Isaac Richards | |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
Currently, there is one major issue with MinGW port of frontend, I am writing this off the top of my head, so may not remember correctly, but the basic idea should be clear: NuppelVideoPlayer? starts video decoding on a separate thread, which somewhere in tv_out.cpp creates an "event loop" and listens for keystrokes. When a key corresponding to program guide is pressed, it creates the program guide widget (still on this thread), and tries to attach it to main window. So here's the problem: in Windows, UI is essentially single-threaded, child windows should all be created on the same thread, if two child windows are created on different threads, SetFocus?() function (inside Win32 API call, not just QT) will deadlock. This is what happens with the current version inside MythMainWindow::attach. I also think that this might be causing timer events not reaching the playback widget, which leads to sound being muted on every channel change.
The problem is, this issue cannot be just "#ifdef'ed" in MinGW port, it needs some upstream change - ideally, all the "widgets" should be created on the main thread by the MythMainWindow?, and instead of implementing event loops inside other classes, there should be just one in MythMainWindow?, and all other widgets should be receiving signals from it.
Ticket #4085 describes similar behaviour (without specifying OS).
This was resolved in 15630 (referenced in 4376). This ticket should be closed.