Timeshifting setting recommendation (1 Viewer)

[enricong]

What are the recommended settings?

What is the advantage/disadvantage of having a larger number of small files vs having a smaller number of large files?

 

[mm1352000]

What are the recommended settings?

The defaults... unless you understand the settings enough to change them.

What is the advantage/disadvantage of having a larger number of small files vs having a smaller number of large files?

Access to more back buffer when your timeshift buffer space is very constrained.

 

[enricong]

I read the wiki and under stand it is saving files to create a buffer. And the minimum number is for the buffer to rewind. and the max number defines how much more to record once you hit pause.

However, I did not see any mention as to the difference between having, for example. 50 250MB files vs 1 12gb file. It adds up to the same amount of time.

I figure maybe there is a difference in terms of overhead with keeping track of more files. And perhaps more delay with opening and closing files more often.

 

[mm1352000]

However, I did not see any mention as to the difference between having, for example. 50 250MB files vs 1 12gb file. It adds up to the same amount of time.

You're right - the wiki doesn't explain everything.

Here's the thing. The difference is subtle and difficult to explain/understand unless you're technically minded or want to spend time really understanding how MP works. By coincidence I was asked to explain this very thing recently. The explanation took more than an hour to write. You can read my answer here:
https://forum.team-mediaportal.com/...lpha-4-2014-02-15.114068/page-30#post-1065222

The short answer is that in most cases it makes no difference. Like I said above, it can make a difference in cases where the timeshift buffer is very small and you're trying to maximise how much back buffer you can get out of it in all scenarios.

Ultimately the point I'd like to convey is that if you don't need to change the setting then don't change it. If you don't know whether you need to change a setting then you probably don't need to change it. There is no harm or shame in not understanding a setting and leaving it at defaults. The defaults are defaults for a reason - to be safe/good values for most people.

 

[enricong]

Thanks, I do need to change it because I'd like a larger buffer. Thats why the question came up, to understand which values to change.

I read through your post and understand the difference now, pretty minor. Now I would assume if this was taken to the extreme and the file size was 1mb to reduce the wasted buffer time, we'd start hitting issues with the overhead of switching files. Ofcourse we're only talking about maybe 2min lost

 

[mm1352000]

I think larger files would take longer to create/allocate (though I could be wrong)... and yes, smaller files would lead to more overhead in switching files.

Primarily the way to increase the buffer size is to increase <minimum> (and <maximum>). The max <minimum> value is 100.

100 x 256 MB = 25600 MB = ~25 GB = normal buffer size
10 Mb/s = 1.25 MB/s
25600 / 1.25 = 20480 seconds / 60 = 341.33 minutes / 60 = 5.688 hours.

If you really need a buffer which is longer than 5.6 hours (or whatever the calculation gives for your source bitrate) then by all means go ahead and bump the file size. Otherwise I suggest just increase <minimum>. I note default <minimum> and <filesize> yields 20 minutes... which for many people is enough.

mm

 

[enricong]

Actually, I was going to ask why not create one file and just track the write pointer and read pointer and keep looping within the file. Depending how it is being done in code it may not make a difference how big the file is when you first open the file. Does it actually need to allocate the space or does it just open a file handle and start writing. Anyways for such a minor inefficiency, maybe it doesnt matter.

Yeah, I just changed minimum and maximum.

 

[mm1352000]

Actually, I was going to ask why not create one file and just track the write pointer and read pointer and keep looping within the file.

What you've suggested is known as a ring buffer. This has been suggested previously though as far as I know nobody has attempted to implement it for MediaPortal. From a technical perspective it is more complex than the current approach, but perhaps "cleaner" or easier to configure/understand from a user perspective.

Also, file size is limited on certain file system types. For example, FAT32 (still moderately common) has a maximum file size of 4 GB. That might be an issue for some people.

Depending how it is being done in code it may not make a difference how big the file is when you first open the file. Does it actually need to allocate the space or does it just open a file handle and start writing.

My understanding is that timeshift buffer file space is pre-allocated to minimise overhead. In other words: writing to file that continuously grows in is more intensive for the storage subsystem than pre-allocating 256 MB and writing into that pre-allocated space.

Anyways for such a minor inefficiency, maybe it doesnt matter.

Don't quote me (I had no part in the original design choices - was long before my time - and I'm not an expert on file systems) but I'm not so sure that the inefficiency is minor. The HDD load/performance in part determines some key things like the maximum number of users and channel change speed. Therefore it makes sense to minimise the load on the HDD where possible.

 

[enricong]

Good points. Its easy to suggest ideas, implementation is another story. When I said minor inefficiency, I was referring to the current implementation and missing out on like 2-3min of your back buffer so its probably pretty low on the list with regards to improvement.

 

[regeszter]

Hi,

However, I did not see any mention as to the difference between having, for example. 50 250MB files vs 1 12gb file. It adds up to the same amount of time.

When the buffer is full, the 1st buffer will be overwited.
If you have 40 x 250MB = 10GB buffer, you will stay 39 x 250 = 9,75 GB when a buffer file is overwited.
If you have 4 x 2500MB = 10GB buffer, you will stay 3 x 2500 = 7,5 GB when a buffer file is overwited.

I think the 1st. is better.