[mythtv] Multiple recording directories

Bruce Markey bjm at lvcm.com
Thu Jan 13 15:47:57 EST 2005


Terry Barnaby wrote:
> Thomas Börkel wrote:
> 
>> HI!
>>
>> VDR lets you have multiple directories for recordings with ascending 
>> number, like "/video0", "/video1", etc. In this case, you just 
>> configure the name "/video".
>>
>> Maybe this is something for MythTV, too?
>>
>> A first step could be, that MythTV just looks into all directories for 
>> playing (not being able to configure, which recording goes where), but 
>> places new recordings in "/video". But then, at least one could 
>> shuffle the recordings around onto other disks or servers.
>>
>> Or maybe the recording directory could be configured per recording group?
>>
>> I don't know, how much work that would be, just had the idea.
> 
> I was thinking along these lines before Christmas when I wanted to 
> temporarily
> add an extra disk for Christmas films to my server.
> I added a bit of code to Myth to allow me to do this, a bit of a hack.

I'm sorry I wasn't aware of the follow symlinks option at the
time or that long thread may have been much shorter.

Even though I still don't need this myself, I did start on
a prototype back in Dec. that allows a colon separated list
for RecordFilePrefix. It correctly splits, reads from and
writes to any of the dirs. Reading from the dirs throughout
the code is pretty easy. For writing, I'd like it to make
these choices:

- prefer not full (above MinRecordDiskThreshold) over full
- prefer local disk over remote mount
- prefer a disk not in use by another recorder over one in use
and if there is still more than one equal choice,
- prefer the disk with the most free space

The remaining problems are determining that a dir is on a local
mount vs any type of remote mount (NFS, Samba, others?). Also
determining which backend is responsible for a directory if it
is shared for reporting total free space properly and which
backend(s) may delete files. This isn't too bad if all NFS
mounts are from disks that are local to another backend, The
local backend would be responsible. However, if one of the
dirs is a disk on a slave and that slave is down or if there
is a shared NFS mount from a system that doesn't run a backend,
exactly one backend has to take charge for that disk.

If this all works, you can have more than one disk on a machine
whose filesystems are not tied together so you can move files off
one to take the disk out, replace it or do maintenance. A slave
could have a local disk and paths to NFS mounts so if the local
disk fills up it could fail over to writing across the network.
A master could have paths to NFS mounts of the slaves' local
disks so the master could play the slaves files even while the
slave backend process is not running (but the machine would have
to be up of course =). Etc.

--  bjm


More information about the mythtv-dev mailing list