Opened 14 years ago
Closed 14 years ago
#7691 closed task (fixed)
Reduce RECORDING_LIST_CHANGE usage.
Reported by: | danielk | Owned by: | danielk |
---|---|---|---|
Priority: | minor | Milestone: | 0.23 |
Component: | MythTV - General | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
Eliminate as many RECORDING_LIST_CHANGE events causing full reloads as possible.
The idea is to send UPDATE_PROG_INFO whenever a single ProgramInfo? changes, and to make RECORDING_LIST_CHANGE events always specify the specific program they are adding or deleting so a full reload is unnecessary.
Attachments (5)
Change History (17)
Changed 14 years ago by
Attachment: | 7691-v1.patch added |
---|
comment:1 Changed 14 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | new → accepted |
comment:2 Changed 14 years ago by
This has been lightly tested now. It doesn't appear to cause any regressions.
Note: programflags are not currently updated when SetBookmark?() called, fixing that would fix the bookmark icon update which is currently still broken. But getProgramFlags() also shouldn't be needed to load flags in the recorded table when the program info was loaded from the recorded table in the first place. And all the flags should be updated as needed to keep the state of the in core ProgramInfo? in sync with its own Set methods, not just the bookmark flag.
Changed 14 years ago by
Attachment: | 7691-v4.patch added |
---|
This theoretically fixes the flag issue, but is untested.
comment:3 Changed 14 years ago by
(In [22955]) Refs #7691. Speeds up Watch Recordings updates by using the less heavy weight UPDATE_PROG_INFO instead of RECORDING_LIST_CHANGE in a number of places.
This also fixes the flag update issue reported in the ticket a few days ago by updating the flags in ProgramInfo? where appropriate.
comment:4 Changed 14 years ago by
(In [22964]) Refs #7691. Don't send events directly to master from slave backends, instead put them on the local queue and let the event code send it on to the master. Not sure why this works better. But it has been reported to be a problem by two people, and Jim Stichnoth confirms this fixes the event storm while still allowing updates to percolate.
comment:5 Changed 14 years ago by
(In [22966]) Refs #7691. Make sure our ProgramInfo? is up-to-date before sending out an update event.
comment:6 Changed 14 years ago by
(In [22968]) Refs #7691. Don't update pathname when we get a ProgramInfo? update event, these could may have been localized.
Ideally we should keep a pristine pathname in each ProgramInfo? and update a non-serialized pathname with any locallized version. Until we reach that level of cleanliness in ProgramInfo? this hack will avoid problems locating the file when we expect it to be localized to the reciever of the update event.
comment:7 Changed 14 years ago by
(In [22974]) Refs #7691. quick n' dirty fix for a recording problem stuart m and otto have been experiencing.
I'm working on a more comprehensive solution, but doing so slowly; this should fix the immediate problem of localized pathnames being overwritten with the basename from the DB when we do a DB refresh of a ProgramInfo?.
comment:8 Changed 14 years ago by
The MythObservable? patch is for the SEGFAULT that occurs when a MythEvent? arrives as we're shutting down the PlaybackBox?. It gets rid of all but one of the unsafe methods in MythObservable? and marks the unsafe method as deprecated (the remaining three methods have been made safe). I believe the only thing still using the one unsafe method is MythMusic, which is slated for an overhaul next year. It has always been documented as a method you should not use, but the deprecated tag makes any new uses of it easier to spot.
Changed 14 years ago by
Attachment: | 7691-event-reduction-v1.patch added |
---|
Reduces event frequency by combining events.
comment:9 Changed 14 years ago by
I forgot to mention, the event reduction patch changes MythProto? again, but doesn't update the protocol version. If you want to try it make sure to install it on all your myth boxes. This also removes all those MythProto? interactions from the UI thread, a step in fixing #7603. To that end there is also a change to mythcontext.cpp to print some debugging on MythProto? interactions from the UI thread, which needs to be removed prior to commit.
comment:10 Changed 14 years ago by
(In [22992]) Refs #7691. Reduces ProgramInfo? update events by combining ones that occur within 50 ms of the first one in a series.
This also changes the MASTER_PROG_INFO_UPDATE to only send the chanid and recstartts. The rest of the info is pulled when this is processed by the master backend.
comment:11 Changed 14 years ago by
(In [22995]) Refs #7691. Segfault fix. Adds a lock to MythObservable?, removes it's unsafe methods, kills in-flight events to a listener being removed and reorders playbackbox teardown to avoid segfault when exiting the PlaybackBox? while an event is being processed.
comment:12 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
The only remaining full RECORDING_LIST_CHANGE happens when a slave backend disconnects from the master. In this case a full list update does make sense. We could instead update only those recordings that are in progress on that particular backend, but this is a pretty rare event so the optimization isn't worth the effort.
Some low hanging fruit, untested.