[mythtv-users] Moving recordings...
Michael T. Dean
mtdean at thirdcontact.com
Mon Feb 9 19:26:09 UTC 2009
On 02/09/2009 09:35 AM, Fred Squires wrote:
> On Thu, Feb 5, 2009 at 8:44 PM, Brad DerManouelian wrote:
> > On Feb 5, 2009, at 2:31 PM, Fred Squires wrote:
> >> On Thu, Feb 5, 2009 at 5:21 PM, stuart wrote:
> >>> Had a conversation w/someone about moving recordings from my
> >>> MBE to my SBE machine. He said "no go". So I'm turning the
> >>> question onto you guys to see if there is any hope...
> >>> My MBE is in need of HDD rearrangement. So I bought a new SATA
> >>> HDD and soon discovered I was out of SATA ports on the MBE. So
> >>> into the SBE the new HDD went. However, my plans to move
> >>> recordings from the MBE to the SBE are up in the air.
> >>> Evidently, the new feature which allows mythtv back ends to
> >>> "find" recordings no matter what directory works only if all
> >>> recordings are confined to a particular machine. That is,
> >>> *not* across different back ends. Or, perhaps, I've
> >>> interpreted the feature incorrectly. Thoughts?
> >>> ...thanks
> >> It'll work if you add them to the same storage group (via nfs or
> >> smb) on your master backend. Of course, doing that will double
> >> your network usage, because the system will have to transfer the
> >> recordings over nfs to your master backend then stream then to
> >> your frontend. You could mount the nfs share on the frontend to
> >> get around that, as long as you backend isn't set to always
> >> stream recordings.
> > I thought you could put them in any storage group and mythtv would
> > look for them in each and fail only after not finding the recording
> > in any of them. Of course, I've been known to be wrong before but
> > trying it would be really easy. :)
> Honestly, my answer could also be wrong.
Myth will check for the recording in all the directories listed for the
Storage Group in which the recording is supposed to be located. If it
doesn't find it there, it will search all accessible Storage Group
First, some terminology:
Storage Group: a logical name given to a group of directories. Note
that a Storage Group is /not/ a directory and a directory is /not/ a
Directory: a location within the filesystem where files, such as
recordings, can be stored. Note that a Storage Group necessarily has at
least one directory associated with it.
In mythtv-setup, you define Storage Groups (SG's) on the master
backend. You may /only/ create new SG's on the master backend.
Running mythtv-setup on a remote backend, you will only see the
already-defined-on-the-master-backend SG's listed. There will be no
button, "(Create new group)". On a remote backend, you may only
override the definition for an SG that has already been defined on the
master backend. In the event that your SG has the same directory list
on the remote host as it does on the master backend, you should not
override the value on the slave backend (i.e. let it "inherit" the value
from the master backend so that you need only change the definition in
one place--on the master backend--when adding new drives, changing
filesystem structure, removing directories, etc.).***
Note that on a remote backend, you may see, "(Create LiveTV group)"
and/or "(Create DB Backups group)" if you haven't already specified
those on the remote backend. These buttons will be available even if
you haven't created those groups on the master backend. However, these
"special" SG's are already "created" by code in Myth and are only
overridden by the user. If the user doesn't override their definition
with the "(Create <special group> group)" buttons, they have the same
definition as the "Default" storage group. Therefore, we're still only
overriding definitions on the remote backend--we're not creating the SG.
When mythfrontend is searching for a recording file, it first checks the
directories listed as belonging to the SG associated with the recording
(assuming the setting, "Always stream recordings from the backend" isn't
enabled in mythfrontend settings under Utilities/Setup|Setup|TV
Settings|Playback). If the file is not found in any directory in the
"proper" SG, it checks directories for the "Default" SG. If it's still
not found, it checks any directory in any SG.
However, things get a bit more complicated, even. Some directories may
be accessible only to some hosts. When looking for the recording file
and falling back (to either the "Default" SG's or to "any" SG's
directory list), Myth does so without regard to hostname. So it
actually checks all directories listed in the "primary" (master backend)
definition as well as the "overridden" definitions of the SG's directory
list. If the directory is not accessible--i.e. it is a remote
filesystem that's not shared or whose permissions do not allow access
(i.e. different UID's/GID's on NFSv3 or below client/server)--it will
/not/ be checked because we don't have access to the directory.****
If after this point, the recording file still isn't found, and the setting:
Master Backend Override
If enabled, the master backend will stream and delete files if it finds
them in the video directory. Useful if you are using a central storage
location, like a NFS share, and your slave backend isn't running.
was enabled in mythtv-setup, and the frontend is not on the same host as
the master backend, the same searches will be performed, but this time
by the master backend. (So, if the master backend has access to a
filesystem that the frontend doesn't, it may find the recording.)
Then, if the recording file still isn't found, the frontend asks the
backend on which the show was recorded to stream the file. This means
that the same search described above is repeated, but this time on the
recording host. So, if the mythbackend on the recording host has access
to a filesystem that the frontend (and possibly the master backend)
doesn't, it may find the recording. In theory--since the recording
host's mythbackend recorded the file--it should always be found there.
When moving recordings across hosts or when redefining SG's, however,
this may not be the case. (Again, see the second note****, below.)
***That being said, currently the only SG whose definition is truly
inherited from the master backend is the "Default" SG. If you have
defined a custom SG on the master backend and have a remote backend, you
would need to "override" the custom SG on the remote backend, otherwise,
Myth will fall back to the "Default" SG on the remote backend. I just
finished a patch for allowing fallback to the master's definition of the
custom SG, but still have to test it before uploading it to Trac. In
the real world, though, this would affect few users as most only define
the "Default" SG (and possibly the special SG's) and/or have only one
backend. And, worst case, if you are affected, Myth would simply write
recordings that are meant for custom SG's to the "Default" SG when
recording on a remote backend, so it's not a big deal/not worth worrying
about. The only reason the patch is required is because it will have an
impact on some forthcoming patches which use the SG code. Therefore,
I've simplified the description above to what will happen after the
patch is committed.
****Therefore, if you have filesystems that are not exported to all your
Myth hosts, some directories may not be checked. In these cases, moving
a recording from one host to a not-accessible directory on another
requires modifying the hostname associated with the recording. If the
directory is accessible to all hosts through a share, the hostname
/probably/ should be changed to allow more efficient transfer. There
are patches in the works which will allow you to move recordings from
within the Myth GUI in 0.22--including updating all relevant DB data--.
More information about the mythtv-users