[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.

Short Answer:
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 
directories.

Long Answer:

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 
Storage Group.

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.)

Mike

***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--.  
Until then...




More information about the mythtv-users mailing list