Michael T. Dean wrote: ...
Line 1222 of programinfo.cpp is the culprit, but unfortunately, I can't see an easy way to fix it. We can't just trim the RecordFilePrefix off the left because it won't work with multiple hosts...
You don't want to allow a server to access to any arbitrary full path.
I can't think of a non-invasive approach to use. Ideas?
Here's what I've written before that I'd like to see but I haven't needed this so far so I'd never gone past some simple proof of concept tests last winter. -- bjm -----------8<-----------8<----------- 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. _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev