2016-06-22, 20:59
In TVH, the duration of the recording is set as soon as the recording starts; this information is taken from the EPG in TVH's database. This listed duration may not actually represent the recording if: 1, the recording was started while the program was in progress; 2, there was an error in the recording and the file was truncated; or 3, if you manually told TVH to record longer than the program (i.e., to extend the recording time of a sports broadcast). In cases 1 and 2 the duration listed in the Recordings screen matches the EPG duration, but when the file is played back, it's length will be shorter. In case 3, the recording will actually be longer than the reported duration.
In all three cases, Kodi will play back the recording regardless of what the EPG data tells it about the recording, because once a recording is chosen for playback, Kodi bases the progress display based upon the file itself, not what TVH is telling Kodi. In cases 1 and 2 above, this means playback will end before the duration because Kodi reaches the end of the file. In case 3, it will continue to play after the duration has lapsed because there is still data in the file being sent to Kodi.
It's the disconnect between the initial Recordings screen displaying information from the EPG/TVH database, and when the recording is actually played the playback information comes from the file itself, no longer from TVH. This is why when you try to seek/fast forward past the end of a recording in progress playback ends: Kodi reached the end of the file, and therefore it believes that playback is finished because it doesn't know that there is supposed to be more data coming in, it just knows that it's not getting any more data.
(It's this behavior, the playback being based on the file itself rather than its guide information or other metadata, that makes me say this is not a bug per se, but rather an idiosyncracy of implementation. What Kodi is doing isn't wrong, because it doesn't know any better. And, until the way that the PVR subsystem in Kodi changes, it is unlikely to change.)
I haven't yet had time to investigate the Unpause Jumpback source to see if it is possible to write a service plugin that pauses playback when the end of the file is reached when viewing a recording in progress. I hope to do that this coming weekend, and if so, perhaps a kludge of some sort could be worked to at least help mitigate this "discrepency".
In all three cases, Kodi will play back the recording regardless of what the EPG data tells it about the recording, because once a recording is chosen for playback, Kodi bases the progress display based upon the file itself, not what TVH is telling Kodi. In cases 1 and 2 above, this means playback will end before the duration because Kodi reaches the end of the file. In case 3, it will continue to play after the duration has lapsed because there is still data in the file being sent to Kodi.
It's the disconnect between the initial Recordings screen displaying information from the EPG/TVH database, and when the recording is actually played the playback information comes from the file itself, no longer from TVH. This is why when you try to seek/fast forward past the end of a recording in progress playback ends: Kodi reached the end of the file, and therefore it believes that playback is finished because it doesn't know that there is supposed to be more data coming in, it just knows that it's not getting any more data.
(It's this behavior, the playback being based on the file itself rather than its guide information or other metadata, that makes me say this is not a bug per se, but rather an idiosyncracy of implementation. What Kodi is doing isn't wrong, because it doesn't know any better. And, until the way that the PVR subsystem in Kodi changes, it is unlikely to change.)
I haven't yet had time to investigate the Unpause Jumpback source to see if it is possible to write a service plugin that pauses playback when the end of the file is reached when viewing a recording in progress. I hope to do that this coming weekend, and if so, perhaps a kludge of some sort could be worked to at least help mitigate this "discrepency".
