On Wednesday 29 June 2005 3:26, Hamish Moffatt wrote: > On Tue, Jun 28, 2005 at 10:17:02PM -0500, Kevin Kuphal wrote: > > Hamish Moffatt wrote: > > >How would it know whether a particular location has sufficient disk > > >space for a scheduled recording? > > > > > > > > How does it know now? If Myth already has a mechanism to deal with > > full disk situations, it will work regardless of where the recording > > is > > destined, as long as it is checking the appropriate location for > > free > > space. Again, this is one of there areas that could be enhanced by > > multiple locations in that if the default location for particular > > recording is full, Myth could be instructed to make various > > decisions on > > whether to expire content from the drive or simply record in a > > different > > location. > > The point is that for MOST recording methods, Myth can't known in > advance whether a recording will fit in a given location. Only PVR-x50 > recordings seem to have predictable file size - DVB, ATSC, RTJPEG etc > do not.
But that's the case currently, anyway. As it is now, we only have a setting that controls the minimum amount of free space that must be available before Myth will start a new recording. There's no guarantee that there is actually enough space to *finish* the recording... you just have to set the number high enough and hope for the best. With multiple storage locations, this wouldn't change, except that you wouldn't look at total free space, you'd look at free space available on any one mount point. > Perhaps you can choose the one with the most empty space and hope > for the best though... Exactly what it's doing now, pretty much. Here's a pie-in-the-sky thought (and I realize this is probably *way* overkill, but it's an interesting idea nonetheless). What if Myth had a sort of virtual filesystem? That is, not a filesystem per se, but more of a content management layer, where a recording could be 'sliced' as it was being recorded, and each slice could potentially reside in a different location (retained in the database, of course). Playback and other file operations would involve locating the various slices and 'stitching' them back together, perhaps in a manner similar to BitTorrent (managing the parts, that is; not sharing over P2P). Of course, all of this is analogous to the way a normal filesystem manages blocks on a device, and even the way LVM or RAID is able make a filesystem span devices. The difference, of course, would be that no special filesystem tools would be required to manage the storage, and changing the storage configuration would be as simple as editing a text field in Myth setup, plus maybe moving some files and updating the database with their new locations. The slice size could be configurable. of course. Then the disk space issue becomes much more manageable, because you only have to check for enough space in a given location for the next slice (which would be a known, fixed size). Just a thought; I'm not suggesting that we *should* have such a system; I'm not even sure if it's a good idea or not. Just something to file in the 'idea closet' :-) -JAC _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
