Timeshift

[Freetime]

Buffer like timeshift? There is very few options for timeshift and worst thing is that there is no limits for the timeshift file. In my case I use "tune channel" to occasionally delete timeshift file and it works quite well to protect that timeshift file don't get too big. Alltought in my point of view some kind of "buffer timeshift" could be improvement for the current timeshift. Where you have timeshift file allocated like windows pagefile in static size or range and screen output video stream is recorded buffer timeshift file with first in last out principle. With this technique you can watch channel in buffer limits whenever you want and then even sudden channel change won't delete your timeshift recorded programs. Currently you lose your timeshift file even you change audio output between A and B.

[Griga]

Such a limited buffer must be a ring buffer, right? If it gets full, writing to it continues at the beginning. We have a write pointer and (on timeshifted playback) a read pointer, indicating the position where the next data is written to resp. read from, both wrapping around.

 

One major problem of such a ring buffer is the variable bitrate of MPEG2/H.264 video. The data rate might change considerably (and in an unpredictable way) while recording/watching. If it increases, the write pointer might catch up with the read pointer, thus creating a big data mess. Anybody out there who knows a clever solution for that?

[Mr. Bun]

I don't know whether it's clever, but here's an idea I posted a while ago.

 

Isn't there another way to achieve low-disc-usage timeshift while avoiding the hazards of a ring buffer?

 

If DVBViewer were to automatically split the timeshift-file every 60 seconds (or so) into incrementally numbered chunks DVBViewer could then delete a chunk of the timeshift-file once it has been replayed (i.e. watched), thereby limiting disc-usage to the space you need for the timeshift-delay plus 2 minutes (at worst).

 

That would, of course, require DVBViewer to be able to automatically and seamlessly play split files as a whole. Which would be a nice feature to have anyway and should, IMHO, not be too difficult to implement. (But what do I know?)

 

One could even allow for some limited (x minutes) backward-seeking by deleting the (n)th-chunk only after the (n+x)th chunk has been replayed.

[erwin]

One major problem of such a ring buffer is the variable bitrate of MPEG2/H.264 video. The data rate might change considerably (and in an unpredictable way) while recording/watching. If it increases, the write pointer might catch up with the read pointer, thus creating a big data mess. Anybody out there who knows a clever solution for that?

 

Yep, such shit happenz.

 

But:

 

I've built a proof-of-concept-plugin of such a ring buffer. It works fine for me. For positioning with the slider of the read pointer i have a dummy zone beetwen read and write pointer and so i have a reserve. The artefacts are tolerable. They occur only sometimes at the end points of the slider bar. Left side when the read pointer catches the dummy zone and then the write pointer. Right side the roles of read and write pointer are changed. All you have to do is to move the slider a bit away.

 

 

erwin

[Griga]

If DVBViewer were to automatically split the timeshift-file every 60 seconds (or so) into incrementally numbered chunks DVBViewer could then delete a chunk of the timeshift-file once it has been replayed (i.e. watched), thereby limiting disc-usage to the space you need for the timeshift-delay plus 2 minutes (at worst).

That would, of course, require DVBViewer to be able to automatically and seamlessly play split files as a whole. Which would be a nice feature to have anyway and should, IMHO, not be too difficult to implement. (But what do I know?)

Difficult, but not too difficult. In the last weeks I've implemented it in TSPlayer experimentally (including the ability to join split files), and it works so far... it's based on a low-level unit allowing the application and the user to handle chunks as a single file. However, it's not designed to deal with removable chunks yet.

 

I've already considered the "divide and conquer" method for timeshift, but there are several practical problems. E.g. users who want to keep the timeshift file(s) as permanent recording would not be amused to find it all cut in pieces. And imagine a one hour timeshift recording and a user skipping one minute backwards from live playback (maybe accidently). According to your suggestion DVBViewer would delete 59 recorded minutes or so without a warning. And so on... ATM there are two conflicting tendencies: In the German section of the forum people are emphatically demanding more persistent timeshift files, while people in the English section want them to be less persistent. So what shall we do? Save a lot of work and leave it as it is, I'd say as a developer