On Wednesday 29 June 2005 13:25, [EMAIL PROTECTED] wrote: > On Wed, 29 Jun 2005 10:58 , 'Joseph A. Caputo' <[EMAIL PROTECTED]> > 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 _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
