Control Over Timeshift Buffer Length and Better/More Reliable Retroactive Recording

[ChaosMageX]

I decided to start another topic because these two features are different from my other requested feature, but both have to do with the timeshift buffer.

First, I would like more control over the length of the timeshift buffer. Currently, I notice that the timeshift buffer only creates about 8 transport stream blocks at a time, each around half a gigabyte in size. I would like to be able to control the size of these blocks and how many are created in a way similar to how MediaPortal allows you to control these aspects:

http://wiki.team-mediaportal.com/1_MEDIA...meshifting

I want to be able to expand the maximum timeshift buffer length to the 90 minutes I'm used to having on my DirecTV R22-100 DVRs, or perhaps even longer, because in my setup I'll basically have an entire hard drive dedicated to holding the timeshift buffer files.

Also, I've noticed that the currently the timeshift buffer only creates 8 transport stream blocks, no matter how many devices are active. I noticed that when I'm watching two shows at once, each show only gets 4 transport stream blocks in its timeshift buffer instead of the full 8 I would get when watching just one show.

This behaviour doesn't make sense to me, as it seems weird to suddenly cut a client's timeshift time in half when another client connects. Consider a situation in which you have two TVs in your house, each with an Android TV box running Kodi and connected to the server running NextPVR. One family member is watching something on one TV, and then suddenly another family member tunes in and watches a different channel on the second TV. Now each person can only rewind half as far back in time.

I can understand the reasoning behind this feature in order to conserve space on the hard drive holding the buffer, but I would like to control whether or not this behavior happens, as I would prefer each client to always be able to rewind live TV an equal amount of time, no matter how many other clients are also connected to the server. I can always take measures to ensure that I use a big enough hard drive to contain the buffer so that conserving space is not an issue.

Second, I want more reliable Retroactive Recording. That is the term I use to describe when a user starts to record a program at a point in time beyond its start time in the EPG, and the timeshift buffer is added to the recording file back to the start time of the program in the EPG (plus any specified pre-padding offset) or the end of the timeshift buffer, whichever is later.

Currently, the only way I can retroactively record a program is by watching that program directly in the NextPVR application on the server running it. When I try to retroactively record a program I'm watching in a Kodi client connected to the NextPVR server, the recording file only goes back to the time I pressed the record button instead of the start time of the program in the EPG, even though I had a timeshift buffer going back past the start time of the program.

Also, when I do retroactively record a program I'm watching in NextPVR application directly on the server, that program's recording file will be saved into timeshift buffer directory instead of into a folder named after the show in one of the designated recording storage directories. This was originally just an annoyance that meant manually moving the recording files to where they should have been saved, but it became a problem when NextPVR DELETED a program I had retroactively recorded when I exited out of the Live TV display and went back to the main menu in the NextPVR application. All that was left was the xml info file in the timeshift buffer directory, which had the same name as the recording file. The recording file itself was completely gone, not in the timeshift buffer directory, not in any of the recording storage directories, not even in the Recycle Bin, and I was not happy about that, at all. :mad:

So yeah, I want more reliable retroactive recording. I want the timeshift buffer to always be added to recording file as close as possible to the EPG start time of the program (plus any pre-padding), and for the recording file to be saved in the appropriate directory instead of the timeshift buffer directory, and not be erased when I exit out of the client on which I was watching that retroactively recorded program.

I'm not sure how complex it would be fully implemented these features, especially when it comes the Kodi NextPVR client add-on, but I do know that NextPVR is already capable of retroactive recording, because I've done it successfully a few times before. I just want it to be handled better.

I thank the developer(s) in advance if they are able to implement these features in the next release of NextPVR, as retroactive recording is something I have relied on with my DirecTV R22-100 DVRs, because I'm sometimes not sure if I want to record a program until halfway through watching it, especially when it comes to news broadcasts.

[mvallevand]

The buffer is controlled by

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NPVR\SlipSeconds = xxxx (decimal DWORD)[Seconds]

I think there are 4 rolling files. For kodi timeshifting this creates another buffer

I prefer EPG mode buffering for live since it always buffers the entire show you are watching from when you started watching. Unfortunately that is not provided to Kodi or http clients, my biggest wish for years.

Martin

[sub]

Also, I've noticed that the currently the timeshift buffer only creates 8 transport stream blocks, no matter how many devices are active. I noticed that when I'm watching two shows at once, each show only gets 4 transport stream blocks in its timeshift buffer instead of the full 8 I would get when watching just one show.

This behaviour doesn't make sense to me, as it seems weird to suddenly cut a client's timeshift time in half when another client connects. Consider a situation in which you have two TVs in your house, each with an Android TV box running Kodi and connected to the server running NextPVR. One family member is watching something on one TV, and then suddenly another family member tunes in and watches a different channel on the second TV. Now each person can only rewind half as far back in time.

That's not how it works. Each client gets up to the maximum buffer size in seconds (which is contained in up to 4 files, specific to that client). The default is a 20 minutes long buffer, but can be overridden for longer period using the registry setting Martin mentions above. ie, you could set it to 5400 to give each client up to 90 minutes of buffer.

Second, I want more reliable Retroactive Recording. That is the term I use to describe when a user starts to record a program at a point in time beyond its start time in the EPG, and the timeshift buffer is added to the recording file back to the start time of the program in the EPG (plus any specified pre-padding offset) or the end of the timeshift buffer, whichever is later.

Watching in NextPVR itself the user can choose to either use the buffering scheme mentioned above (based on time), or they can use EPG based buffering (which splits the files at show boundaries). The latter has the advantage of being about to keep the whole show if the user hits 'record'. I'm not aware of any reliability issues with it. I'm considering extending this to clients like Kodi etc in the future.

Also, when I do retroactively record a program I'm watching in NextPVR application directly on the server, that program's recording file will be saved into timeshift buffer directory instead of into a folder named after the show in one of the designated recording storage directories.

The reason it ends up in the timeshift buffer directory is because this is where the file already exists. Some people have recording directory on different drives, or even network drives, and moving potentially many gigabytes of data to another volume can be hard on the system even causing distruptions to the live tv session or recording. It's a lot easier on the system to leave the file where it already is. I may look at some sort of post-recording auto move in the future though.