Feature #1087: DVR Improvements
Only post-restart part of recording is available in UI if tvheadend is restarted in mid-timer recording
If tvheadend is restarted whilst recording a scheduled programme, it is indeed clever enough to resume recording. It does this to a new file that has "-1" inserted in the filename (or "-2" etc. if it's a second etc. restart). However, the original filename is then completely ignored in the Recorder schedule, so playing back the recording will only play from the latest post-restart point onwards, which might only be a fraction of the whole programme.
Solutions to this might include some attempt to join all the parts together into a single file (risky, because the ends of each part might be truncated) or display all the parts (with some indicator to show the part number) and let the user pick which ones to play back.
It should also be noted that deleting such a restarted recording will only delete the latest recording file and leave all the previous parts on the filestore with no way from the Web UI to delete them.
Updated by Adam Sutton over 10 years ago
- Tracker changed from Bug to Feature
- Assignee deleted (
- Parent task set to #1087
I'm re-classifying this as an FR, since its not a bug this is the way it's intended to work (though you could probably argue about the deleting being a bug).
TVH is obviously designed with the assumption that it will always run and not be interrupted while recording, the number postfix is merely to stop it overwriting an existing file which could be linked to another recording (though in this case is linked to the same).
I have plans to do some work on the DVR code in 3.3 (see #1087), so any input welcome. Possibly using file stacking similar to XBMC (for multi-part episodes) might be a very simple solution.
Updated by Flole Systems about 5 years ago
This is actually still an issue, recordings that have been interrupted are not shown properly.