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)

7691-v1.patch (8.6 KB) - added by danielk 14 years ago.
Some low hanging fruit, untested.
7691-v3.patch (23.3 KB) - added by danielk 14 years ago.
Updated patch -- down to one full reload.
7691-v4.patch (35.3 KB) - added by danielk 14 years ago.
This theoretically fixes the flag issue, but is untested.
7691-mythobservable-fix-v1.patch (11.1 KB) - added by danielk 14 years ago.
fix for a segfault
7691-event-reduction-v1.patch (13.6 KB) - added by danielk 14 years ago.
Reduces event frequency by combining events.

Download all attachments as: .zip

Change History (17)

Changed 14 years ago by danielk

Attachment: 7691-v1.patch added

Some low hanging fruit, untested.

comment:1 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk
Status: newaccepted

Changed 14 years ago by danielk

Attachment: 7691-v3.patch added

Updated patch -- down to one full reload.

comment:2 Changed 14 years ago by danielk

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 danielk

Attachment: 7691-v4.patch added

This theoretically fixes the flag issue, but is untested.

comment:3 Changed 14 years ago by danielk

(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 danielk

(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 danielk

(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 danielk

(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 danielk

(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?.

Changed 14 years ago by danielk

fix for a segfault

comment:8 Changed 14 years ago by danielk

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 danielk

Reduces event frequency by combining events.

comment:9 Changed 14 years ago by danielk

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 danielk

(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 danielk

(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 danielk

Resolution: fixed
Status: acceptedclosed

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.

Note: See TracTickets for help on using tickets.