Reply to thread

Message: <blockquote data-quote="mnmr" data-source="post: 1065648" data-attributes="member: 86308">Great, let's see what we can come up with. And thanks for the lengthy write-up! I think I understand how it works at this point, but still have a few questions before we get to solutions.First you say this:But then later you note that:Why does sharing (TsReader can access the file being written to) work when playback starts, but not for subsequent files? I'm not sure if Windows allows you to open a file for writing if someone is reading from the file, but I know you can do the reverse. Not that this is really important - it sounds like it is only the file at "end" of the circular buffer where this problem arises.OK, so if we assume that its possible to deduce a reasonable file size automatically (let's get back to that later), we could probably agree to get rid of the setting in the UI.I hope so. Let me try to re-explain it using the graphic below, to make sure <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink    ;)" loading="lazy" data-shortname=";)" /><img src="https://dl.dropboxusercontent.com/u/5591288/MPTS.jpg" alt="" class="fr-fic fr-dii fr-draggable " style="" /> The green bar illustrates the concept of a timeshift buffer, segmented into a number of blocks (files, A-H in the above). As you start watching TV, blocks will be written to allow for rewinding. Until you pause, your playback position will be the same as where data is written (at the end of the current block). Thus, the MP "minimum" controls the maximum number of blocks allocated for rewinding (I'm glossing over any details like -1 to keep things simpler). The difference between MP "min" and "max" controls the number of additional blocks MP can allocate when you have a full rewind buffer ("min" blocks have been allocated) and pause playback. If min/max are the same, no extra space will be allocated when you pause (instead, the oldest rewind block will be reused). When playback continues to be paused until "max" blocks have been saved, recording stops (essentially, MP prefers to lose live signal over automatic resume of playback).I cant check right now, but think the TvSetup program has a bug that lead my understanding astray. Only by increasing the file size and the min value would it show a higher estimated recording time - but editing max should also have resulted in updated values.Let's turn our attention to a possible solution. As far as I can tell, the only benefit you get from having both min and max is that you do not always allocate the full timeshift buffer. But that is not really useful, since you need to keep the space free anyway - so MP might as well allocate it. I'd also bet that there is no measurable performance cost from using more files (e.g. 100), so we might as well use a fixed amount.With a full allocation and fixed block/file count there are only two relevant things left to configure. The first is the block size, which then decides how big the timeshift buffer will be in total. And the second is the division of the space into rewind/forward buffers - something like a percentage slider would work well for this. In practice, using 40% for rewind would correspond to min of 40 and max of 100. I'd probably make the percentage control an advanced setting - most users are fine with sensible defaults in my experience. I'd also consider using minutes instead of file size, and change the labels to show the space required (currently it is the reverse), but mostly because minutes is much less techy than GiB or some such.Thoughts? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" /></blockquote>

Verification