Thanks again, I'll go with AC3filter - sounds like it'll fix one of my major gripes with the Sonos gear!
Testbuilds for Native MP2 TV - Updated for 10th AE Update 1 (2014-09-13)! (2 Viewers)
- Thread starter morpheus_xx
- Start date
Thanks again, I'll go with AC3filter - sounds like it'll fix one of my major gripes with the Sonos gear!
I am going to take another swing at the timeshifting options in TvSetup
I have tried, but still fail to grasp what these settings do. I'd like to think that I'm not particularly stupid and I'm certainly fairly tech-savvy, which makes me think that these options are inexplicable to most end-users. Assumptions are always a bad idea, but I'd be surprised if it was not a long-term goal to make MediaPortal more end-user friendly.
It also appears that the only option making any sense is the minimum, since only by increasing that can I modify the maximum recording time (I already set the file size to its max, and in fact wonder why there is a limit of only 1GB/file; of course, why I need to know MP saves stuff in multiple files is also beyond me).
I have maxed all three settings: 100 minimum, 100 maximum and 1GB/file, but I'm not sure what the effect of that is (other than that I expect my pause functionality to work for at least half a day before it continues playback).
I have tried, but still fail to grasp what these settings do. I'd like to think that I'm not particularly stupid and I'm certainly fairly tech-savvy, which makes me think that these options are inexplicable to most end-users. Assumptions are always a bad idea, but I'd be surprised if it was not a long-term goal to make MediaPortal more end-user friendly.
It also appears that the only option making any sense is the minimum, since only by increasing that can I modify the maximum recording time (I already set the file size to its max, and in fact wonder why there is a limit of only 1GB/file; of course, why I need to know MP saves stuff in multiple files is also beyond me).
I have maxed all three settings: 100 minimum, 100 maximum and 1GB/file, but I'm not sure what the effect of that is (other than that I expect my pause functionality to work for at least half a day before it continues playback).
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
It is certainly a long term goal of mine to make MediaPortal more end-user friendly... but I'm not sure what I would do to make those three options more friendly except to improve documentation.
Let me try to lay this out with a semi-technical description of how timeshifting works from first principles. I'm describing it this way only because I know you're a developer and I hope you will understand and as a consequence be able to suggest how we could simplify or better explain the options.
You turn on the TV. TV Server's TsWriter component creates 1 file of size <filesize> and starts writing the stream from the tuner to the file. Shortly afterwards MediaPortal's TsReader component starts reading from the start of the file. This is live TV - yay!
Initially the file contents is garbage; just allocated space. Over time the buffer fills up with real content. TsWriter writes and TsReader follows. When the buffer is completely full TsWriter needs a new file to enable live TV to continue, so it will create another file of size <filesize> and start filling up that buffer in exactly the same way as the first file. TsReader will also jump into the new file once it reaches the end of the first file.
This process can continue for quite some time... but not forever. Eventually you'd run out of HDD space and bad things would happen. This is where the <minimum> setting comes in. Once TsWriter has created and filled <minimum> buffer files, the next time it needs a buffer it will reuse the oldest buffer. So in other words we have a kind of ring buffer strategy here. MediaPortal could now go on showing live TV forever using <minimum> files for the lifetime of the HDD.
Hopefully you understand to this point?
Okay, now let's start with the slightly more interesting stuff. Let's say for some reason you want to watch the last X minutes of live TV again. Of course this is possible. MediaPortal/TsReader will allow you to seek backwards within the available back-buffer. Assuming you have watched TV for long enough to fill <minimum> files and haven't paused at any time, the size of the available back buffer will be <minimum> - 1 files.
A point here about <filesize>: it becomes a factor due to the -1 above. Consider two configurations:
1. minimum = 6, filesize = 256 MB
2. minimum = 3, filesize = 512 MB
For all intents and purposes the total buffer size is the same at 1.5 GB... but when it comes to seeking there is a difference. In configuration 1 TsReader will have access to at least (5 x 256 MB = 1.25 GB) of buffer space for seeking; in configuration 2, only (2 x 512 = 1 GB). Yes this is absolutely very technical and not a justification for exposing the filesize setting. Just a hint to remember HDD space wasn't always so cheap. This might have made a difference for some people back in the dark ages when MP was new (2004, 2005).
Back to the example...
So TsReader can skip backwards and forwards within the available back buffer. When TsWriter switches to another file, TsReader loses access to the contents of that file.
Now let us add the next level of complication: you want to make a cup of coffee so you pause TV. TsWriter will continue to need buffer files while you're enjoying your coffee. It will reuse the back buffer files as normal. When you return you can unpause and continue watching from where you left off, though you won't be able to seek back as far. Fine.
Let's say while you're having your coffee somebody phones you and the conversation takes longer than expected or your family needs you to do something... and... and... and... eventually you forget you paused TV. What will TsWriter do while you're gone? Well, eventually it will get to the file/buffer that TsReader was reading from. It won't be able to use that file because TsReader has locked it. Since that file can't be reused, TsWriter will start creating new files again.
We're now back to a situation where TsWriter could continue creating files until it completely fills your HDD and bad things happen. This is when the <maximum> setting comes into play. It is the absolute maximum "you must stop creating files now" limit. TsWriter will create new files until it reaches the <maximum> number of files. If <maximum> is reached and you still haven't returned from your cup-of-coffee-which-turned-into-a-round-the-world-trip we finally start to throw away new data.
Hopefully this all makes sense now.
For most people the defaults should be fine. 6 x 256 MB gives about 20 minutes of back buffer for 10 Mbps h.264 HD content; double for SD at 5 Mbps. If you want longer than that then simply increase the minimum according to the bitrate of your channels, your available HDD space (usually not a concern these days) and your desired back buffer size.
For <maximum>: 20 x 256 MB gives an hour of 10 Mbps HD. If you really think you'll be gone for an hour and then come back and unpause... well maybe consider increasing.
If I were recommending settings for a person new to MediaPortal that likes to fiddle with settings but doesn't have all day to learn what everything means from first principles I'd say:
1. Default <filesize> (256 MB) should be fine unless free space is an issue (eg. RAM disk or SSD). Otherwise maybe reduce to 100 MB.
2. Set <minimum> such that <minimum> x <filesize> = the back buffer you want TV Server to give access to in normal circumstances.
3. Set <maximum> such that <maximum> x <filesize> = the largest amount of space you ever want TV Server to use for timeshifting.
I don't know for sure why the file size setting is exposed. It was added long before I joined the team. Probably even before I started using MP.
Behind the scenes the implementation does need multiple files. There is a limit to file sizes with FAT16 and FAT32 file systems which means you can't just have your 100 x 1 GB in one huge buffer file. These days with people trying to eek out space on RAM disks and SSDs it is perhaps useful to have the setting available for advanced users. Doubtless this wasn't the original purpose...
If all else fails, set everything to 100%.
At 10 Mb/s, 100 GB of buffer space is probably more like 22 or 23 hours... but who's counting...
mm
@mm1352000: You are pretty awesome at explaining stuff
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:
You turn on the TV. TV Server's TsWriter component creates 1 file of size <filesize> and starts writing the stream from the tuner to the file. Shortly afterwards MediaPortal's TsReader component starts reading from the start of the file. This is live TV - yay!
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.
Yes this is absolutely very technical and not a justification for exposing the filesize setting. Just a hint to remember HDD space wasn't always so cheap. This might have made a difference for some people back in the dark ages when MP was new (2004, 2005).
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.
Hopefully this all makes sense now.
I hope so. Let me try to re-explain it using the graphic below, to make sure
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?
Minutes is less techy but far more difficult to work out given that X minutes of HD takes a different amount of space to X minutes of SD. You could probably quote a value for each using a simple max file size (or current free space whichever is smaller) / amount of space 1 minute takes up. If you've got enough free space to timeshift more than it's practical to watch then it won't matter if the quotes aren't 100% accurate
Most thing are obvious, once you know the answer. But most people don't even have the terminology required for understanding that screen, and even if they do, they want to install an HTPC and not pass a minor math exam in the process.
Anyway, this is purely my opinion on the matter. I believe strongly in it and thus advocate for change, but whether someone agrees and decides to simplify the process of configuring MP is another matter
The tool already does this (it shows estimated HD/SD recording times). The formula is the same, you simply swap which variable the user enters.