[mythtv-users] Moving recordings...

[Michael T. Dean]

On 02/18/2009 08:52 AM, stuart wrote:
> Michael T. Dean wrote:
>> On 02/09/2009 07:41 PM, stuart wrote:
>>> Michael T. Dean wrote:
>>>> ****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...
>>>>
>>> Thanks for taking the time to replay.  I'm thinking the answer to my
>>> specific situation is above.
>>
>> Based on your original post, I'm thinking the answer to your question
>> is the "..." in, "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..." portion of my post. 
>> I chose not to enumerate the options.
>>
>>>   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? 
>>
>> While MythTV doesn't care if an SG lists a directory that is not
>> accessible (doesn't exist, has permissions that prevent access, ...),
>> whether your system would actually find them is very much dependent
>> on your complete system (including network, filesystem including
>> shares/exports, and MythTV) configuration.
>>
>> You should read the "****" second note from my post.  What to do with
>> that information, I'll leave up to you.  But I will say that you
>> should /definitely/ start with: 
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore
> A follow up...
>
> Thanks Mike for explaining how mythtv works and will work in the next
> release.
>
> You are right, when I added the new HDD to my SBE I started out
> wanting to move recordings off my MBE.  As I became aware of the
> difficulties I reverted the issue to only adding the new HDD to the
> SBE.  My understanding, from your previous post, was this was possible
> and was to be done by telling the MBE about the new storage space.  So
> I ran mythtv-setup on the MBE and added the new directory where I
> mounted the new HDD on the SBE to the default recordings group.   I
> used the mythweb status page to check my storage status but the new
> HDD did not show up.  So, I ran mythtv-setup on the SBE and did the
> same as on the MBE. Checking mythweb I saw the new HDD.  I started a
> recording and, probably because all other HDD space was full, mythtv
> dropped it into the new HDD.  It appears all is well.
>
> So, did I not understand what you said -or- is it possible I did (am
> doing) something wrong?

Sounds right.

Two points of note...  If you have recording directories (for the
"Default" SG) available at the same location on both the master backend
and the remote backend, you only need to define the SG on the master
backend.  Usually, people have this setup because they mount the
directories identically on all systems using network mounts.  (So, mount
the local recording drive at /srv/mythtv/recordings1 on the master
backend and export it so you can mount that same drive at
/srv/mythtv/recordings1 on the remote backend.  Then, mount the local
recording drive at /srv/mythtv/recordings2 on the remote backend and
export it so you can mount it at the same location on the master
backend.)  It doesn't hurt to "override" directory locations on a remote
backend--even when unnecessary--and for now may make sense to do so,
especially for non-"Default" SG's.

If you have network mounts in place, you may think that Myth will record
to whichever directory is least full, but in fact it will record to the
/local/--not network mounted--directory that's least full (assuming all
other weights are identical).  In other words, it will happily
autoexpire a recording from the full local disk even when you have an
empty 1.5TB HDD available through a network mount.  That means your
master backend will generally write to its own HDD's and the remote
backend will write to its own hard drives.  (There is much more to
directory selection than just available space, so my saying, "will
generally write," is my acknowledgment that I'm leaving out a large part
of the story.)  If you have /only/ network mounts on one or more
backends, that backend will write to all of the directories.

If you don't have network mounts in place, then backends can /only/
write recordings to the local drives.

Therefore, for either reason, it makes sense to try to spread out
recordings to leave approximately the same amount of available space on
each backend's local drives.  So, that may mean you still need to move
recordings.  If so, let me know.

I took care to spread out my input connections to account for the
backend's preference for local drives.  I connected inputs such that 1
is on the master backend, 2 and 3 are on the slave backend, and 4 is on
the master backend (as many recordings occur singly--therefore, get
stored on the master backend--fewer will occur in doubles, even fewer as
triples, and the fewest as quadruples; so this setup tends to balance
usage).  I have 4 pcHDTV HD-3000's (2 in each backend), so--since
they're identical--there's no reason to prefer one over another.  If you
don't have identical cards, you should connect inputs in the same way,
but ensure that you have your most-preferred input as 1, your
2nd-most-preferred as 2, etc. (which may mean moving capture cards to
balance usage /and/ preserve priority).  Use the video source portion of
http://www.gossamer-threads.com/lists/mythtv/users/264034#264034 to
reorder input connections.

Mike