[mythtv-users] Confused about secondary backend storage - howto use it (trunk)?

[Chris Pinkham]

* On Wed Dec 26, 2007 at 01:16:10PM +0000, Jose Bernardo Silva wrote:
> My problems:
> 1 - I'd like the secondary /home/myth always leave 10 GB free, can I
> set that independently?

Not currently.  There is one global setting since the master copy of
mythbackend handles scheduling and autoexpiration of all storage.  If
anyone wants to work on adding such a feature, it needs to be done in
conjunction with Storage Groups since users could want different
amounts of space free on different filesystems on the same backend.

> 2 - transcoding fails frequently, as the master tries to use the
> secondary to transcode files recorded on the master, and tries to
> transcode on the master files recorded on the secondary. I've set the
> "transcode only on same backend" option, but still this happens. What
> can I do?

Logs might help in this case.  I've been unable to replicate this
issue in the past.  When you turn on the setting that says that jobs
must run on the recording host, then it sets the hostname in the
jobqueue table.  That means that only that host can run that job.
Run your backends with the "-v jobqueue" option and see if there are
any clues in there as to why the job is being picked up on the wrong
backend.

> 3 - how can I archive on the master files recorded on the slave?

If both backends are running full-time, I'd cross-mount their storage
directories.  This will give you the most flexibility and allow the
Storage Group scheduling code to be most efficient.

Here's a sample setup similar to yours.  Each host exports all
recordings directories via NFS and mounts the other host's directories
via NFS in the same location as the remote host.

Host1
/video/host1/dir1 (local)
/video/host1/dir2 (local)
/video/host2/dir1 (nfs mounted)

Host2
/video/host1/dir1 (nfs mounted)
/video/host1/dir2 (nfs mounted)
/video/host2/dir1 (local)

Just use the Default Storage Group on the master backend and add all
three directories to it.  You can delete the 'Default' group on the
slave backend, the slave will use the dirs from the master's Default
group if a local Default group does not exist.

This will allow Myth to optimize storage from a disk space standpoint
as well as utilizing the best spindles when you're recording.

> 4 - I have a frontend, with 120GB free, but which is only on when
> watching tv or movies. What is the better way to use the free storage
> on that one? I don't want a "permanent" mount as it won't be always
> on.

You can fairly easily use this 120GB for 'archived' shows that you'll
probably never want to delete.  Using my above Host1/Host2 notation,
we'll call this Host3.

Say you have a /video/host3/dir1 directory where you want to keep
recordings.  This doesn't have to be a separate partition or filesystem,
remember Storage Groups use directories and doesn't care whether
they are the one same filesystem or different ones.  The Storage Groups
code is smart enough to understand the different filesystems and plan
accordingly, but it doesn't require you to use different filesystems.

Anyway....  Run mythtv-setup on your frontend or master backend and
add a new 'Archived' Storage Group.  Add the /video/host3/dir1 directory
to this group.

Manually move some of your recording files to this directory on the
frontend and mythfrontend will now be able to find them if you want
to play them back.

If you wanted to get fancy and automate things, you do something
like this:

1) setup a tunerless backend on the frontend
2) mount the master and slave backend's dirs on the frontend
3) setup the /video/host3/dir1 directory and Storage Group as
   described above.
4) setup a manually-run User Job to move files from the master or
   slave's recording directory to the frontend's directory and update
   the 'hostname' field in the mythconverg.recorded table for that
   recording to be the frontend's hostname.
5) Configure the JobQueue settings page on the frontend to only allow
   this 'mover' User Job so mythcommflag/mythtranscode don't interfere
   with playback on your frontend.  Configure the settings page on
   the other backends to _not_ allow this User Job to be run on them.
6) Move files from the host1/host2 servers by manually scheduling the
   new User Job and leaving the frontend up long enough for the job
   to be processed.

In this scenario, you would be able to play these files as normal
since the frontend has direct access to the files.  Since the tunerless
backend is running on the frontend, you could delete files as normal
since the master could tell this slave backend to delete the files which
are local to it.  When the slave (aka frontend) is offline, the master
wouldn't try to do anything with its files like auto-expire, etc..  
As long as you have only one frontend then this would work.  As soon as
you add another frontend into the mix, then it means that frontend wouldn't
be able to play all recordings if the first frontend was down since the
files stored on the first frontend would be inaccessible.

--
Chris