home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 2
Plugin Development
Testbuilds for Native MP2 TV - Updated for 10th AE Update 1 (2014-09-13)!
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="mm1352000" data-source="post: 1065222" data-attributes="member: 82144"><p>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.</p><p></p><p></p><p>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.</p><p></p><p>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! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>Hopefully you understand to this point? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>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.</p><p></p><p>A point here about <filesize>: it becomes a factor due to the -1 above. Consider two configurations:</p><p></p><p>1. minimum = 6, filesize = 256 MB</p><p>2. minimum = 3, filesize = 512 MB</p><p></p><p>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). <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>Back to the example...</p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>Hopefully this all makes sense now. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>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.</p><p>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.</p><p></p><p>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:</p><p>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.</p><p>2. Set <minimum> such that <minimum> x <filesize> = the back buffer you want TV Server to give access to in normal circumstances.</p><p>3. Set <maximum> such that <maximum> x <filesize> = the largest amount of space you ever want TV Server to use for timeshifting.</p><p></p><p></p><p>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.</p><p>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...</p><p></p><p></p><p>If all else fails, set everything to 100%. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p>At 10 Mb/s, 100 GB of buffer space is probably more like 22 or 23 hours... but who's counting... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p></p><p>mm</p></blockquote><p></p>
[QUOTE="mm1352000, post: 1065222, member: 82144"] 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%. :D At 10 Mb/s, 100 GB of buffer space is probably more like 22 or 23 hours... but who's counting... :D mm [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
Plugin Development
Testbuilds for Native MP2 TV - Updated for 10th AE Update 1 (2014-09-13)!
Contact us
RSS
Top
Bottom