[mythtv-users] Moving recordings...

[stuart]

Michael T. Dean wrote:
> 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...
> 

Hi Mike...

Thanks for taking the time to replay.  I'm thinking the answer to my 
specific situation is above.  But I'm afraid I'll need to ask it 
regardless.

I added a 1/2TB HDD to my slave back end (the master back end it too old 
to handle another SATA HDD) and wanted to start using it to store 
recordings.  Both the MBE and SBE store recordings in the directory 
/space/recordings.  I'll probably create another directory on the SBE 
called /more_space/recordings.  From what I understand, I need to tell 
the MBE to add the directory /more_space/recordings to the mythtv 
Storage Group. This, regardless that there is no such directory on the 
MBE.  This action should allow the SBE to start using the new HDD to 
store recordings.  And, it shouldn't bother the MBE that it will not 
find this directory.

Do I have that right?

...thanks