[mythtv] Re: New idea for storing recordings to disks

[Joseph A. Caputo]

On Wednesday 29 June 2005 13:25, danielk at cuymedia.net wrote:
> On Wed, 29 Jun 2005 10:58 , 'Joseph A. Caputo' <jcaputo1 at comcast.net> 
> sent: 
> >(1) if your auto-expire space threshold  is not at least as large as 
> >the max number of bytes a recording could consume in , you could 
> >still run out of space (not too likely, but possible)
> >(2) if auto-expire runs, but there's nothing that can be expired, 
> >you're  
> >hosed
> 
> >Bottom line is still, to *guarantee* you won't run out of space 
> >mid-recording, you must set the new recording space threshold high 
> >enough, figuring in factors like multiple tuners and transcoding jobs 
> >that may also consume space.
> 
> Actually, the code in SVN guarantees that you won't run out of space 
if
>  1/ There are sufficient recordings to autoexpire AND
>  2/ Any shared disk is shared with the master backend AND
>  3/ Any non-myth application's disk usage is accounted for in the
>    'extra space' disk space reservation on each backend.
>  4/ There are no problems with deleting the files. This might happen
>     if you are watching a program that MythTV wants to autoexpire.
> 
> So (1) is mostly taken care of, (2) should be solved with a warning to
> the user and a graceful abort of any ongoing recordings.
> 
> Solving (1) for multiple disks won't be a 1 day project, but it isn't
> rocket science. You can estimate the amount of space a recording will
> take with GetMaxBitrate() and the length of the recording. Then you
> just have to determine what needs to be deleted on each disk to fit
> the next recording (don't pre-delete it however), and then pick the
> least objectionable one. You can then have use the existing AutoExpire
> functionality, simply create one for each disk on each backend.

Yep.  I think we've all managed to converge on this conclusion by 
different paths :-)

-JAC