Unnecessary delays in performing merge when saving current event's timeshift

[prl]

If another recording is running when the "record post-padding" merge is done on a save of the current event's timeshift buffer, the merge will be delayed until no recordings are running on the PVR.

This may have been appropriate on less powerful PVRs but doesn't seem to be so on the T series.

If necessary, the higher-priority I/O activities of the PVR might be more conveniently safeguarded from interference by the merge by using ionice on the merge jobs.

Replication steps

Create a recording timer that will overlap the time of end of the current live TV event + the value of MENU>Setup>TV>Recording settings>Margin after recording. The timer should extend a reasonable time past the end of the recording margin, say 10 minutes.

Save the current event by using REC>Select an event to save>Current Event: *event name.

When the event ends, a recording is started to capture the post-padding (margin after) for the current event timeshift save. In the media browser, the saved timeshift will appear to be two recordings, the timeshift save itself and the post-padding recording.

When the post-padding recording timer ends, the explicit timer set at the start of the replication steps should be running. The start of the merge process for the timeshift recording will be delayed until 2min30 after the end of the explicit recording.

After that, the merge process will run normally.

NB: this process can be affected by Bug #490: Save current timeshift event sometimes saves the event's .sc file. The timing will be as described, but the merge result may not be correct. In particular, the merged file may only have the result of the post-padding recording, and/or may have problems being played correctly.