Skip forward in current recordings

Markus Bonet

Sometimes there is an ongoing recording and I want to play it back while it's still being recorded.

Of course this works for ages but the time information on the recording is just a few seconds in Kodi.

Therefore, skipping 5 minutes ahead takes quite a long time.

Is it a misconfiguration somewhere in my setup?

I use Matroska as the format to be recorded to, may this be related?

Let's assume there is a recording planned for 60 minutes and 40 are already recorded. I would expect to present the recording with the full 60 minutes to Kodi and that seeking in the file is rather quick.

For obvious reasons, skipping beyond the 40 minutes will not work ;-)

Any hint?
Possible a new feature/enhancement?

Robert Cameron

Yes, this is a side-effect of using Matroska containers, as they aren't great for streaming.

For best results, especially if you have a desire to view in-progress recordings in Kodi is to use an MPEG-TS container. Your program duration will not increase past when you started viewing the recording, but this is a known Kodi bug/shortcoming. Of course, as long as it has recorded beyond that point in time, you will be able to view/seek beyond the indicated end (at least until you reach the live portion of the recording—seeking beyond "now" during an in-progress recording will be treated as "Stop").

Markus Bonet

OK, thanks for the explanation.

How does Kodi receive information about the duration of a recording? I am thinking whether it's possible to give back an estimated duration based upon the planned recording.

Edit: I checked the setting and now I can see the difference. The already recorded time is being presented to Kodi. Seeking is fine within this time range. Now the question remains whether the duration is read from some kind of header so it could be faked.

Robert Cameron

Markus Bonet wrote:
> OK, thanks for the explanation.
> How does Kodi receive information about the duration of a recording? I am thinking whether it's possible to give back an estimated duration based upon the planned recording.
>

> Edit: I checked the setting and now I can see the difference. The already recorded time is being presented to Kodi. Seeking is fine within this time range. Now the question remains whether the duration is read from some kind of header so it could be faked.

No, the duration for recordings is based upon the file itself when it is opened for playback. If you play/seek beyond the "end" when a recording is still in progress, as long as there is data in the file, it will continue to play (and incrementally update the duration for as much of the file that it has actually accessed). But, move beyond the end of the data (by accidentally seeking too far forward during an in-progress recording) and playback will end.

Markus Bonet

How does streaming/timeshift work in this manner?
Of course w/o timeshift, the demuxed stream is just streamed to Kodi.

But there is valid time information on that "file" as well. Expected length, current timestamp etc.

Isn't it an idea to handle records in the same way, independent of how it's recorded to the disk?

Robert Cameron

Markus Bonet wrote:
> How does streaming/timeshift work in this manner?
> Of course w/o timeshift, the demuxed stream is just streamed to Kodi.
> But there is valid time information on that "file" as well. Expected length, current timestamp etc.
>

> Isn't it an idea to handle records in the same way, independent of how it's recorded to the disk?

No, Live TV (streaming/timeshifting) and playback of Recordings are two separate and different things. In Kodi, they are handled by different components. Live TV doesn't have the problem of trying to seek beyond the end of the current now/live point in time because Kodi treats this as a continuous stream. Recordings are treated exactly the same as Movies or TV Shows in your Library, not as if they were live streams.

Linux Convert

Is there any work being done on changing the nature of the add-on to treat recordings as if they are a live stream?

I only ask because I previously used windows media center as my pvr backend, and in-progress recordings displayed with the total time of the program, and a status bar that showed not only how much I had watched but how much had been recorded to that point. It would update as I skipped through and when I hit the end of the amount recorded would continue to play just as if I skipped to live on a timeshift scenario.

This is a nice feature to have, so maybe someone could put in a feature request with the pvr add-on? WMC is the only backend I know of with this ability, but I have zero coding/development knowledge so forgive me if this is much more complex an issue.

Thanks to all who have contributed to TVH, it has made my media server experience smooth and very low maintenance.

Robert Cameron

The API for Kodi 18 has been changed to allow recorded program to be treated as live streams, which would solve the problem of seeking beyond the current live position of a recording-in-progress stopping playback. Also, there are some abilities in the API to present the duration of a recording-in-progress as the full EPG duration and not just the length of the recorded file when playback started. However, whether those features are implemented is up to the developer of the pvr.hts addon. (That addon is written by a third party and is not really part of Tvheadend.)

However, the lack of some metadata (such as season/episode information) for recordings is the responsibility of Tvheadend. Currently, Tvheadend does not support retrieving this information over HTSP, and therefore it is not implemented in the Kodi addon. (At least, that's according to the addon developer. If Tvheadend does support this additional message, he is unaware of what the HTS messages are to get that information.)