Opened 18 years ago
Closed 18 years ago
#1720 closed patch (fixed)
skip redundant updates in mythwelcome
| Reported by: | Owned by: | paulh | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.20 |
| Component: | mythtv | Version: | 0.19 |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
Problem: After the frontend exits mythwelcome can get overwhelmed with all the schedule and recording list update events which were fired while it was blocked. It kicks off a platoon of handlers which is pointless given that they're all doing the exact same thing at the same time.
Solution: Allow only one update at a time based on a handler pending flag. In a fit of over-engineering I guard flag accesses with mutexes to protect those lucky ones with hyperthreading.
Result: On my epia it can take 10 seconds to chew through a dozen SCHEDULE_CHANGE events but with this patch it never takes more than a second or so to get the display up-to-date. Doesn't sound like much but the only time I ever pay attention to the "next recording" bit is right after exiting mythfrontend so having a prompt update gives my pvr that Quality Software feel.
Attachments (1)
Change History (3)
Changed 18 years ago by
| Attachment: | welcome.diff.gz added |
|---|
comment:1 Changed 18 years ago by
| Owner: | changed from Isaac Richards to paulh |
|---|---|
| Status: | new → assigned |
I thought I'd taken care of multiple custom events getting queued up while the frontend was running by calling
gContext->removeListener(this)
just before running the frontend. It must not be working the way I thought it was.
Actually I can see why it's not working now. The backend is sending these SCHEDULE_CHANGE and RECORDING_LIST_CHANGED messages to the event socket in Mythwelcome but because its blocked waiting for the frontend they don't get processed and dispatched until the frontend exits. By this time the listener has been put back. Doh!!
da patch