Opened 18 years ago
Closed 18 years ago
Last modified 17 years ago
#4376 closed task (fixed)
Handle keypresses in the main UI thread (refs #4230 and #4085)
| Reported by: | Owned by: | danielk | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.21 |
| Component: | mythtv | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
Handling keypresses outside of main UI leads to events and dialogs being created on different threads and not being handled properly. On Windows, this leads to:
a) mythfrontend deadlocks when trying to switch to program guide from livetv. b) muteTimer never fires, sound stays muted after any seek or channel change.
The overhead associated with creating separate threads the way it is currently being done seems to be unnecessary, but I could be missing something. The proposed patch processes keypresses on the main thread, which fixes both problems.
If the patch cannot be accepted as is, we need to look for a similar solution, as having a single UI thread is the only way to have application behave predictably on Windows.
Attachments (3)
Change History (15)
by , 18 years ago
| Attachment: | threading.patch added |
|---|
comment:1 by , 18 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 18 years ago
| Milestone: | 0.21 → unknown |
|---|---|
| Type: | patch → task |
comment:3 by , 18 years ago
Ok, how about this: process events as usual in the RunTV() thread, but send some of the requests (EPG and unmute timer) back to the main thread for actual processing. This looks a lot cleaner to me compared to even what we currently have, and it solves this critical Win32 issue. See tv_play.patch.
by , 18 years ago
| Attachment: | tv_play.patch added |
|---|
comment:4 by , 18 years ago
| Milestone: | unknown → 0.21 |
|---|
That sounds good in theory, I'll review the patch when I get a chance.
comment:5 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:6 by , 18 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
by , 18 years ago
| Attachment: | ticket_4376_causing_embedded_playbackbox_to_hang.diff added |
|---|
comment:7 by , 18 years ago
changeset[15630] causes embedded playbackbox to hang. attached patch leaves embedded playbackbox as a thread and also cleans up the function pointer associated with it.
comment:8 by , 18 years ago
Can someone confirm if this breaks "Jump to Program" from within LiveTV? It seems to hang while starting.
Thanks, Mark.
comment:9 by , 18 years ago
(In [15717]) Refs #4376. revert back to using new thread for call to embed tv player in the playerbox container since [15630] causes a hang when trying to use this feature. not sure if this breaks MINGW compability. also made some minor changes the function pointer calls associated with it. did this change cause I plan to soon add ability to view upcoming schedule list while watching a show.
comment:10 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Andrei, if Stanley's revert/fix caused a problem with MINGW please reopen.
comment:11 by , 18 years ago
(In [15745]) Fix the call to RunProgramFind() in tv_play.cpp. [15630] should have changed the call to this as well when the event handling was changed. This should fix the frontend hanging with recent SVN when you tried to popup the Program Finder while watching a recording.
References #4376.
Key and network control commands both have to be processed in the RunTV() thread for TV class to remain in a consistent state.
I'm sure MS Windows allows for multi-threaded GUIapplications, there are probably just some additional limitations. We need to trace the reason for the deadlock when switching from the program guide from LiveTV, and QTimer can be replaced with something that works on MS Windows. QTimer in particular causes its own thread-safety problems in Linux and OS X anyway.