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

[Tony Lill]

Kevin Kuphal <kuphal at dls.net> writes:

> Brandon Beattie wrote:
>
>>Recordings would work like this.  Just like in various mythplugins you
>>would be able to specify various locations to store recordings to.  This
>>wouldn't be hard of course.. if that directory doesn't have enough
>>space, use another directory. If no directories exist, expire a file
>>from the directory with the most amount of space in it.  Of course there
>>could be different ways to expire, move files, to balance used space..
>>
>>Comments?
>>
> I've had this idea in my todo list for a while.  Quite simply, I would
> add a column to the recorded table that would store the storage group
> (as an integer number).  There would be a new storagegroup table that
> would, at first, simply be a numericaly indexed list of
> RecordingPrefixes.  If no storage group was specified for a recording,
> it would fall back to RecordedFilePrefix as the current system does.
> Recording profiles could be assigned to a storage group so all new
> recordings would be saved there and also exisiting recordings could be
> moved between groups.

What I was thinking of is two tables, one for the physical storage
space, which would hold the path, hostnaname, priority, and any other
stuff we want; and another to hold the access method of the spaces on each
node. Basicly a global mount table for myth.

This simplifies the code that figures out if files are local or
not. That is if they can be accessed directly or you need to got
through the myth protocol. Also, it doesn't tie you to mounting all
the disks in the same location on all boxes. 

It's also easy to extend to handle removable disks. If you archive to
CD, you leave a record in the physical storage table, and flags it as
removable. If you want to access it, myth looks through the mount
table and find a mountpoint that can handle the media. All you need
then is a popup to tell the user to load the CD labled blah onto some
machine, and Bob's your uncle.

> The reason I imagined a separate table would be for more advanced
> features where each storage group could have their own expiration
> settings, etc. The coding itself is probably very easy for this basic
> functionality.  There are only a handful of places that use Recorded
> FilePrefix.  Of course this is just the foundation work for some of
> the things you mentioned in regards to Myth making choices about where
> to store files.  I simply was interested in it because I don't want to
> use LVM (for the reasons you noted) or RAID when I could just as
> easily use different mountpoints if only Myth would have the ability
> to use more than one.

That's what I thought before I started grubbing through the code.
Acutually, there's about 2 dozen places where it's used directly or
indirectly, assuming I havn't missed something. You also need to think
about calculating free space and how it's used, re-writing urls,
checking if files are local or not, the transcoder and the userjob
stuff.

You'll want to make a new class for it, so you can hide stuff, and
probably also want to change how you use it. Generating a filename for
a new recoring is now much different than finding and existing
recording.

The free space stuff probably needs a persistent object, since you
want to know real free space, and space that's recoverable with an
autoexpire. You don't want to calculate this when you're about to
start recording! Another complication is that autoexpire is really a
priority, not a flag, so high autoexpire priority is more free-able
than low priority. You maybe want a threshold, above which a program
really counts as free space.
--
Tony Lill,                         Tony.Lill at AJLC.Waterloo.ON.CA
President, A. J. Lill Consultants        fax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2     (519) 241 2461
--------------- http://www.ajlc.waterloo.on.ca/ ----------------
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"