The defaults... unless you understand the settings enough to change them.What are the recommended settings?
Access to more back buffer when your timeshift buffer space is very constrained.What is the advantage/disadvantage of having a larger number of small files vs having a smaller number of large files?
You're right - the wiki doesn't explain everything.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.
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.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.
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.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.
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.Anyways for such a minor inefficiency, maybe it doesnt matter.
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.