[mythtv] mutliple storage directories idea... ?

[Steve Adeff]

On Tuesday 01 November 2005 11:58, Kevin Kuphal wrote:
> mythtv at merkx.demon.nl wrote:
> >>>LVM does not work across multiple server machines.  I could
> >>>certainly posit wanting to use the 200G drives from 5 different
> >>>servers and NFS mounting them.  You can't combine them with
> >>>LVM.
> >>
> >>I wonder if you could use iSCSI to share the drives from multiple
> >>servers and combine them with LVM
> >>
> >>Kevin
> >
> >Yes, you could, but only on a block level. All servers would always need
> >to be up-and-running simultaneously, otherwise LVM will not activate the
> >volumegroup.
> >Also, the contents of the disks would only make sense on the server
> >running LVM: it would not be possible to access the data on one of the
> >other 5 servers.
> >
> >So: although possible, probably not a good idea.
>
> True.  Once I sent it I starting thinking, jeez, a reboot would really
> mess that LVM up.
>
> :)
>

Another reason to have improved multiple storage directories support. The perl 
script is a nice start, but not what I would consider a proper solution. I 
wish I could help actually code an improved version, but all I can offer are 
ideas... That said, I do have some questions about how the script and 
database operate:
1. I don't understand the requirement for transcoded shows that remain in the 
recordings database be .nuv as opposed to say .avi? is this purely a naming 
convention issue or can the MythTV playback engine not able to play avi 
files?
2. why can't the database contain not just the file name but also the 
directory under which that file is contained? Would this not eliminate the 
need for the symlinking? Consider the fellow that said he had 300+ Simpsons 
recordings. Wouldn't it make some sense if he could place them all 
in /blah/blah/Simpsons and then have the database look for the files there 
via a directory entry than having to have 300+ symlinks in his normal 
recording directory?

This, it would seem, would be a first step in multiple recording directory 
support. Sure the algorithms for where to place the next recording could be 
worked out later, but it would seem that the perl script currently used could 
be simplified to just moving the file and placing the new directory in the 
database for that recording.

Thanks,
Steve