Mailing List Archive

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Max
> Sent: Thursday, July 31, 2003 4:18 PM
> To: MythTV Mailing List
> Subject: [mythtv-users] Multiple directories for MythTV recordings?
>
>
> Can MythTV use multiple directories or sub-directories for finding
> recordings? My Myth box has a relatively small drive and I would like to
> keep most of the recordings on my NFS filer, however recording straight to
> the filer proved to be too much for my setup (I am yet to figure
> out why) so
> I would like to be able to move the files without having to edit the db.


Don't know if this would work, but...

what if you ran a slave mythbacked process on your NFS server. No tuner
card, so it won't try to record anything. After the master backend has
recorded a program, you could copy the files over to the slave backend's
storage directory. When the files are not found on the master backend, it
will (I think?) query the slave backend for them. Should be not much load
on your NFS box, since all the slave backend would be doing is serving files
for playback (not encoding, decoding or GUI). Actually, now that I think
about it, if you set it up so that your NFS-mounted storage directory has
the same path on both your frontend (NFS client?) and slave backend (NFS
server), when you play it back it will play directly from the NFS-mounted
storage directory, so you don't even need a second backend running. The
only other thing you'd probably have to do is update the 'recorded' table
for the moved recordings to reflect the new storage host and path. You
could easily automate both the NFS copy/move and the database update with a
script.

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

Sounds like a neat solution. The only potential pitfall I can see is what
will happen if the recording is being viewed while transfer is in progress.
Also I cannot run slave backend on the nfs server (it's actually a winblows
appliance, I've considered loading linux on it, but decided it is not worth
the trouble and time to mess with it.) but I can set up a backend on one of
the non-myth linux servers and access it via NFS. But would it not be easier
to just update the storage path on same server and read it via NFS without
need for second backend? Is the path global for the server or is it set per
file?

-M

>
> Don't know if this would work, but...
>
> what if you ran a slave mythbacked process on your NFS server. No tuner
> card, so it won't try to record anything. After the master backend has
> recorded a program, you could copy the files over to the slave backend's
> storage directory. When the files are not found on the master backend, it
> will (I think?) query the slave backend for them. Should be not much load
> on your NFS box, since all the slave backend would be doing is serving
files
> for playback (not encoding, decoding or GUI). Actually, now that I think
> about it, if you set it up so that your NFS-mounted storage directory has
> the same path on both your frontend (NFS client?) and slave backend (NFS
> server), when you play it back it will play directly from the NFS-mounted
> storage directory, so you don't even need a second backend running. The
> only other thing you'd probably have to do is update the 'recorded' table
> for the moved recordings to reflect the new storage host and path. You
> could easily automate both the NFS copy/move and the database update with
a
> script.
>
> -JAC
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I am also of the opinion that it would be nice to
support multiple record directories. I'm not even
thinking about doing anything fancy with nfs or other
backends ... I just want to be able to add more HDD's
to my current backend as easily as possible.

I have an 80 gig drive setup with all my recordings
and system setup on it ... now what if i want to add
another drive for more recording storage? I have
never really messed with raid, but from my
understanding you wouldn't be able to raid 2 drives
once 1 is already full of data.

This just seems like a feature that would be well
worth supporting.


--- Max <max-mythtv-users@lasevich.net> wrote:
> Sounds like a neat solution. The only potential
> pitfall I can see is what
> will happen if the recording is being viewed while
> transfer is in progress.
> Also I cannot run slave backend on the nfs server
> (it's actually a winblows
> appliance, I've considered loading linux on it, but
> decided it is not worth
> the trouble and time to mess with it.) but I can set
> up a backend on one of
> the non-myth linux servers and access it via NFS.
> But would it not be easier
> to just update the storage path on same server and
> read it via NFS without
> need for second backend? Is the path global for the
> server or is it set per
> file?
>
> -M
>
> >
> > Don't know if this would work, but...
> >
> > what if you ran a slave mythbacked process on your
> NFS server. No tuner
> > card, so it won't try to record anything. After
> the master backend has
> > recorded a program, you could copy the files over
> to the slave backend's
> > storage directory. When the files are not found
> on the master backend, it
> > will (I think?) query the slave backend for them.
> Should be not much load
> > on your NFS box, since all the slave backend would
> be doing is serving
> files
> > for playback (not encoding, decoding or GUI).
> Actually, now that I think
> > about it, if you set it up so that your
> NFS-mounted storage directory has
> > the same path on both your frontend (NFS client?)
> and slave backend (NFS
> > server), when you play it back it will play
> directly from the NFS-mounted
> > storage directory, so you don't even need a second
> backend running. The
> > only other thing you'd probably have to do is
> update the 'recorded' table
> > for the moved recordings to reflect the new
> storage host and path. You
> > could easily automate both the NFS copy/move and
> the database update with
> a
> > script.
> >
> > -JAC
> >
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users@snowman.net
> >
>
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
> >
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
>
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

>>>> alleng4@yahoo.com 8/1/2003 11:14:35 AM >>>
>I am also of the opinion that it would be nice to
>support multiple record directories. I'm not even
>thinking about doing anything fancy with nfs or other
>backends ... I just want to be able to add more HDD's
>to my current backend as easily as possible.
>
>I have an 80 gig drive setup with all my recordings
>and system setup on it ... now what if i want to add
>another drive for more recording storage? I have
>never really messed with raid, but from my
>understanding you wouldn't be able to raid 2 drives
>once 1 is already full of data.
>
>This just seems like a feature that would be well
>worth supporting.

It sounds like you should try out LVM. LVM will
allow you to add as much disk space as you need,
over as many drives as you need. You will probably
have to re-make your filesystem if you already have
a system set up, but this would be a good option
if you are just starting out in making a MythTV system
(which is what I am currently doing).

Check out:
http://www.mythtv.org/docs/mythtv-HOWTO-19.html#ss19.15
http://www.ibiblio.org/pub/Linux/docs/HOWTO/LVM-HOWTO

*
Chris Wieringa
cwieri39@calvin.edu


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Max
> Sent: Thursday, July 31, 2003 5:44 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Multiple directories for MythTV recordings?
>
>
> Sounds like a neat solution. The only potential pitfall I can see is what
> will happen if the recording is being viewed while transfer is in
> progress.
> Also I cannot run slave backend on the nfs server (it's actually
> a winblows
> appliance, I've considered loading linux on it, but decided it is
> not worth
> the trouble and time to mess with it.) but I can set up a backend
> on one of
> the non-myth linux servers and access it via NFS. But would it
> not be easier
> to just update the storage path on same server and read it via NFS without
> need for second backend? Is the path global for the server or is
> it set per
> file?
>
> -M

Right; hence the second part of my message. You don't actually need a
second backend. All you need is an NFS server, and the approrpriate entries
in the Myth database to make it *think* that there's a second backend.
There is a setting "Master backend override", or something like that, that
tells the frontend to see if it can access the recording through its local
filesystem (even if that 'local filesystem' is really NFS). If it can, it
will play directly from the filesystem without asking the backend to stream
the file. This feature was initially put in to allow for the fact that
people with slave backends might want to access recordings that were hosted
on those slave backend machines even when the slave backend process wasn't
running on those machines. So, basically, what you'd be doing is fooling
Myth into thinking that there was a slave backend, but that it just isn't
running at present. Never mind the fact that it will *never* be running.
:-)

As for how to figure out a way to automate the file movement without
disrupting a potential in-progress playback... nothing comes immediately to
mind.

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Quoting "Allen T. Gilliland IV" <alleng4@yahoo.com>:

> I am also of the opinion that it would be nice to
> support multiple record directories. I'm not even
> thinking about doing anything fancy with nfs or other
> backends ... I just want to be able to add more HDD's
> to my current backend as easily as possible.

this is where LVM can be useful (as long as you don't want redundancy)
my backend has a 30Gb drive and I'm going to join it with a 40Gb i've liberated
from another machine.

you can also shrink/grow LVM logical volumes (think partitions).
we use this at work, kickstart a machine with a default LVM setup and then grow
/var/log if it's a log server or grow /var/spool if it's a mail server etc etc

> I have an 80 gig drive setup with all my recordings
> and system setup on it ... now what if i want to add
> another drive for more recording storage? I have
> never really messed with raid, but from my
> understanding you wouldn't be able to raid 2 drives
> once 1 is already full of data.

you could mirror it but that's probably not the raid level you were after =]

you're kinda stuck AFAIK, unless you can backup the first 80Gb drive somewhere
else. this is why I used LVM from the start, knew I'd need more space

you can expand an existing software raid array using raidreconf
http://unthought.net/raidreconf/index.shtml

there's been several success reports on the linux-raid mailing list but it's
still classed as experimental

> This just seems like a feature that would be well
> worth supporting.

it's possible using software outside of MythTV, so i guess it won't be too high
priority.

how do Tivo/ReplayTV et al handle multiple disks?


--
Daniel Quinlan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

> you're kinda stuck AFAIK, unless you can backup the first 80Gb drive somewhere
> else. this is why I used LVM from the start, knew I'd need more space

If you're adding a second "larger" disk, you can do this by
creating a Logical Volume on the new disk, copying everything, and then
extending the volume group to the orignal partition/disk. LVM is so cool.
Of course this will all work much better if your media files are in a separate
partition so you don't have to muck around with moving the system (in
other words, it's going to be much harder if you've just got one big
"/". It can still be done, but you'll need to boot from CD and play some
games.) For anyone setting up a new Myth box I highly recommend:

1) Using LVM
2) Put the media storage in a separate LV from the OS.

-poul

>
> you're kinda stuck AFAIK, unless you can backup the
> first 80Gb drive somewhere
> else. this is why I used LVM from the start, knew
> I'd need more space
>
>
Put a second drive in that's bigger than 80GB. Create
a logical volume with at least as much space as you
have MythTV files on the first drive and put a
filesystem on it. Move your MythTV files over to the
new logical volume.

Next, remove the partition you had the MythTV files in
on the first drive. Create a logical volume of the
same size. Concatinate this logical volume with the
logical volume on the second drive. Now you have
a single filesystem that totals the space you had
on both drives.

Mike

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

On Fri, 1 Aug 2003, Joseph A. Caputo wrote:

> As for how to figure out a way to automate the file movement without
> disrupting a potential in-progress playback... nothing comes immediately to
> mind.

I'd suggest trying it. It should 'just work' due to the way *NIX works.
Remember that rm doesn't actually delete the file, it only does an unlink.
If a play process has the file open the inode's link count won't drop to
zero until the player closes the file at which point the system will free
the space.

--
John M. http://www.beau.org/~jmorris This post is 100% M$ Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r

I am thinking about adding a 160 gig partition to my LVM setup of
100+80+80 gig of mythtv storage. I may have to do some acrobatics to
get the cabling where it needs to be. If I plug and unplug ide cables,
so long as hda remains hda, hdb remains hdb and so forth and so on, will
I corrupt my current LVM storage? I probably will If I change the
ordering of the drives.

On Fri, 2003-08-01 at 19:50, Mike Smith wrote:
> >
> > you're kinda stuck AFAIK, unless you can backup the
> > first 80Gb drive somewhere
> > else. this is why I used LVM from the start, knew
> > I'd need more space
> >
> >
> Put a second drive in that's bigger than 80GB. Create
> a logical volume with at least as much space as you
> have MythTV files on the first drive and put a
> filesystem on it. Move your MythTV files over to the
> new logical volume.
>
> Next, remove the partition you had the MythTV files in
> on the first drive. Create a logical volume of the
> same size. Concatinate this logical volume with the
> logical volume on the second drive. Now you have
> a single filesystem that totals the space you had
> on both drives.
>
> Mike
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ______________________________________________________________________
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

running into the maximum of 255 Gig limitation of default setting LVM.
FYI for anybody just starting their LVM setups. If you want an LVM of
greater than 255, you have to set a physical extents size of greather
than 4 MB with vgcreate. You cannot adjust this except at creation of
the vg. I dont know what the trade off is though.



On Fri, 2003-08-01 at 23:58, cmisip wrote:
> I am thinking about adding a 160 gig partition to my LVM setup of
> 100+80+80 gig of mythtv storage. I may have to do some acrobatics to
> get the cabling where it needs to be. If I plug and unplug ide cables,
> so long as hda remains hda, hdb remains hdb and so forth and so on, will
> I corrupt my current LVM storage? I probably will If I change the
> ordering of the drives.
>
> On Fri, 2003-08-01 at 19:50, Mike Smith wrote:
> > >
> > > you're kinda stuck AFAIK, unless you can backup the
> > > first 80Gb drive somewhere
> > > else. this is why I used LVM from the start, knew
> > > I'd need more space
> > >
> > >
> > Put a second drive in that's bigger than 80GB. Create
> > a logical volume with at least as much space as you
> > have MythTV files on the first drive and put a
> > filesystem on it. Move your MythTV files over to the
> > new logical volume.
> >
> > Next, remove the partition you had the MythTV files in
> > on the first drive. Create a logical volume of the
> > same size. Concatinate this logical volume with the
> > logical volume on the second drive. Now you have
> > a single filesystem that totals the space you had
> > on both drives.
> >
> > Mike
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > http://sitebuilder.yahoo.com
> >
> > ______________________________________________________________________
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users@mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
> ______________________________________________________________________
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Saturday, cmisip wrote:

> running into the maximum of 255 Gig limitation of default setting LVM.
> FYI for anybody just starting their LVM setups. If you want an LVM of
> greater than 255, you have to set a physical extents size of greather
> than 4 MB with vgcreate. You cannot adjust this except at creation of
> the vg. I dont know what the trade off is though.

I'm not exactly sure what the tradeoff is, but the new default PE size
for the latest version of LVM (fresh from Sistina) is 32MB.
-jcw

> -----Original Message-----
> From: mythtv-users-bounces@mythtv.org
> [mailto:mythtv-users-bounces@mythtv.org]On Behalf Of John Morris
> Sent: Friday, August 01, 2003 9:38 PM
> To: Discussion about mythtv
> Subject: RE: [mythtv-users] Multiple directories for MythTV recordings?
>
>
> On Fri, 1 Aug 2003, Joseph A. Caputo wrote:
>
> > As for how to figure out a way to automate the file movement without
> > disrupting a potential in-progress playback... nothing comes
> immediately to
> > mind.
>
> I'd suggest trying it. It should 'just work' due to the way *NIX works.
> Remember that rm doesn't actually delete the file, it only does
> an unlink.
> If a play process has the file open the inode's link count won't drop to
> zero until the player closes the file at which point the system will free
> the space.

D'oh! Of course, you're right... I can't believe I missed that!

-JAC