Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

storage directories

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


msmall at eastlink

Jul 10, 2010, 12:15 PM

Post #1 of 15 (3167 views)
Permalink
storage directories

Hi everybody,

I've got a strange problem that I'd like to track down. I have 2 backends,
master and slave. The master has two large hard disks, each with partition
set aside to hold lots and lots of recordings. These are shared with NFS.
The slave just has a smallish drive for OS. The slave actually does most of
the recording, since that is where most of the cards are.

However, I'm finding that the slave is saving some of its data to its own
drive. From a frontend in the machine status screen of the info centre, I see
this:

MythTV Drive #1:
Directories:
master:/mnt/store
slace:/mnt/store
A GB total, B GB used ...
X hours...
Y hours ...

Mythtv Drive #2:
Directories:
master:/mnt/store2
slave:/mnt/store2
A GB Total ...
X Hours...
Y Hours...

Mythtv Drive #3
Directory: slave:/var/lib/mythtv
A GB Total ...
X Hours...
Y Hours...

Now I don't recall ever settings this third storage directory.
When I use mythtv-setup on the slave, and go to the storage directories
option, it just lets me create Default group, create liveTV group and so on.

On the master, I just have the Default group define, with the first 2 folder
listed.

So here's my question: How do I stop recording to the third directory (the
one on the slave)? I'd like to be able to turn the slave off when its not
being used, but I forsee problems if one of my backends want to watch a
recording that is stored on the slave. Also, I don't want to fill up an OS
partition with recordings.

Any ideas?

Mark


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


raymond at wagnerrp

Jul 10, 2010, 1:34 PM

Post #2 of 15 (3100 views)
Permalink
Re: storage directories [In reply to]

On 7/10/2010 15:15, Mark J. Small wrote:
> So here's my question: How do I stop recording to the third directory (the
> one on the slave)?
>

Remove that directory from any storage groups that it shows up on in
mythtv-setup on the slave backend, and then restart the backend.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


msmall at eastlink

Jul 11, 2010, 3:56 PM

Post #3 of 15 (3063 views)
Permalink
Re: storage directories [In reply to]

On July 10, 2010 17:34:08 Raymond Wagner wrote:
> On 7/10/2010 15:15, Mark J. Small wrote:
> > So here's my question: How do I stop recording to the third directory
> > (the one on the slave)?
>
> Remove that directory from any storage groups that it shows up on in
> mythtv-setup on the slave backend, and then restart the backend.

Sounds great, except that the directory isn't in any storage groups on the
slave. In fact there are no storage groups defined on the slave. Maybe I
should create one?

Mark


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jul 11, 2010, 4:59 PM

Post #4 of 15 (3066 views)
Permalink
Re: storage directories [In reply to]

On 07/11/2010 06:56 PM, Mark Small wrote:
> On July 10, 2010 17:34:08 Raymond Wagner wrote:
>> On 7/10/2010 15:15, Mark J. Small wrote:
>>> So here's my question: How do I stop recording to the third directory
>>> (the one on the slave)?
>> Remove that directory from any storage groups that it shows up on in
>> mythtv-setup on the slave backend, and then restart the backend.
> Sounds great, except that the directory isn't in any storage groups on the
> slave. In fact there are no storage groups defined on the slave. Maybe I
> should create one?

It's inherited from the master backend. Remote backend storage group
/directory lists/ simply override the lists defined on the master
backend. Or, put another way, you can /define/ storage groups (SG names
and their associated list of directories) only on the master backend;
you simply (and only) override storage group directory lists on the
remote backends. This is exactly why the /proper/ solution for the
majority of users is to do as you've done--define storage groups /only/
on the master backend. Then, when you want to add or remove a directory
from a storage group, you only need to make that change in a single
location--the master backend's mythtv-setup.

IMHO, the /only/ reason anyone should ever specify a list of directories
on anything other than the master backend is if the user has
misconfigured his/her system and for some reason wants to use a specific
directory name only on one system or another but--and here's the
"misconfiguration" part--for some crazy reason has created said
directory on the system that shouldn't use that directory.

The master backend should have a list of *all* directories used by *all*
hosts. You may add a directory path for a directory that exists on all,
some, or only one of the hosts (even if it doesn't exist on the master
backend).

http://www.gossamer-threads.com/lists/mythtv/users/423104#423104 has a
much more extensive description.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


raymond at wagnerrp

Jul 11, 2010, 6:38 PM

Post #5 of 15 (3058 views)
Permalink
Re: storage directories [In reply to]

On 7/11/2010 18:56, Mark Small wrote:
> On July 10, 2010 17:34:08 Raymond Wagner wrote:
>
>> On 7/10/2010 15:15, Mark J. Small wrote:
>>
>>> So here's my question: How do I stop recording to the third directory
>>> (the one on the slave)?
>>>
>> Remove that directory from any storage groups that it shows up on in
>> mythtv-setup on the slave backend, and then restart the backend.
>>
> Sounds great, except that the directory isn't in any storage groups on the
> slave. In fact there are no storage groups defined on the slave.
>

If no storage groups are defined on a slave backend, it will fall back
to using storage groups defined on the master backend that are found on
the local file system.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


msmall at eastlink

Jul 12, 2010, 2:17 AM

Post #6 of 15 (3048 views)
Permalink
Re: storage directories [In reply to]

On July 11, 2010 20:59:22 Michael T. Dean wrote:
> On 07/11/2010 06:56 PM, Mark Small wrote:
> > On July 10, 2010 17:34:08 Raymond Wagner wrote:
> >> On 7/10/2010 15:15, Mark J. Small wrote:
> >>> So here's my question: How do I stop recording to the third directory
> >>> (the one on the slave)?
> >>
> >> Remove that directory from any storage groups that it shows up on in
> >> mythtv-setup on the slave backend, and then restart the backend.
> >
> > Sounds great, except that the directory isn't in any storage groups on
> > the slave. In fact there are no storage groups defined on the slave.
> > Maybe I should create one?
>
> It's inherited from the master backend. Remote backend storage group
> /directory lists/ simply override the lists defined on the master
> backend. Or, put another way, you can /define/ storage groups (SG names
> and their associated list of directories) only on the master backend;
> you simply (and only) override storage group directory lists on the
> remote backends. This is exactly why the /proper/ solution for the
> majority of users is to do as you've done--define storage groups /only/
> on the master backend. Then, when you want to add or remove a directory
> from a storage group, you only need to make that change in a single
> location--the master backend's mythtv-setup.
>
> IMHO, the /only/ reason anyone should ever specify a list of directories
> on anything other than the master backend is if the user has
> misconfigured his/her system and for some reason wants to use a specific
> directory name only on one system or another but--and here's the
> "misconfiguration" part--for some crazy reason has created said
> directory on the system that shouldn't use that directory.
>
> The master backend should have a list of *all* directories used by *all*
> hosts. You may add a directory path for a directory that exists on all,
> some, or only one of the hosts (even if it doesn't exist on the master
> backend).
>
> http://www.gossamer-threads.com/lists/mythtv/users/423104#423104 has a
> much more extensive description.
>
> Mike

Thanks, Mike.

Since the mysterious storage directory is not listed in mythtv-setup on either
the master or the slave, is there any way that I can find out where it came
from and how to get rid of it? Is it some old cruft sitting in the database
from way back when (I don't remember what version I started with, maybe 0.14
or so).

The slave backend was my original master (and only) backend. The mysterious
directory only showed up with version 0.22 or 0.23, also around the time that
I switched master backend duties with my new file server (an ARM based QNAP
NAS device). I may have originally and briefly used the mysterious storage
directory when I was first testing mythtv, before I added a massive (for its
day) 160 GB hard drive to hold recordings.

Is it time to go digging in the database?

Mark
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jul 12, 2010, 9:08 AM

Post #7 of 15 (3028 views)
Permalink
Re: storage directories [In reply to]

On 07/12/2010 05:17 AM, Mark Small wrote:
> On July 11, 2010 20:59:22 Michael T. Dean wrote:
>> On 07/11/2010 06:56 PM, Mark Small wrote:
>>> On July 10, 2010 17:34:08 Raymond Wagner wrote:
>>>> On 7/10/2010 15:15, Mark J. Small wrote:
>>>>> So here's my question: How do I stop recording to the third directory
>>>>> (the one on the slave)?
>>>> Remove that directory from any storage groups that it shows up on in
>>>> mythtv-setup on the slave backend, and then restart the backend.
>>> Sounds great, except that the directory isn't in any storage groups on
>>> the slave. In fact there are no storage groups defined on the slave.
>>> Maybe I should create one?
>> It's inherited from the master backend. Remote backend storage group
>> /directory lists/ simply override the lists defined on the master
>> backend. Or, put another way, you can /define/ storage groups (SG names
>> and their associated list of directories) only on the master backend;
>> you simply (and only) override storage group directory lists on the
>> remote backends. This is exactly why the /proper/ solution for the
>> majority of users is to do as you've done--define storage groups /only/
>> on the master backend. Then, when you want to add or remove a directory
>> from a storage group, you only need to make that change in a single
>> location--the master backend's mythtv-setup.
>>
>> IMHO, the /only/ reason anyone should ever specify a list of directories
>> on anything other than the master backend is if the user has
>> misconfigured his/her system and for some reason wants to use a specific
>> directory name only on one system or another but--and here's the
>> "misconfiguration" part--for some crazy reason has created said
>> directory on the system that shouldn't use that directory.
>>
>> The master backend should have a list of *all* directories used by *all*
>> hosts. You may add a directory path for a directory that exists on all,
>> some, or only one of the hosts (even if it doesn't exist on the master
>> backend).
>>
>> http://www.gossamer-threads.com/lists/mythtv/users/423104#423104 has a
>> much more extensive description.
> Since the mysterious storage directory is not listed in mythtv-setup on either
> the master or the slave, is there any way that I can find out where it came
> from and how to get rid of it? Is it some old cruft sitting in the database
> from way back when (I don't remember what version I started with, maybe 0.14
> or so).

Yes, it's old cruft, but not from 0.14 (Since Storage Groups were added
for MythTV 0.21, but I know what you were saying ;). It's actually
cruft from having overrides of the Storage Group directory lists on
other hosts that you're no longer using, now. Unfortunately, the only
(supported) way to get rid of directory overrides for no-longer-existing
hosts is to use mythtv-setup on the master backend and actually delete
the entire Storage Group (highlight the Storage Group name and hit D).
Remember that a Storage Group is a name--not a directory--so you're
deleting something like "Default" or "My Recordings" or ... (not a
directory entry in the Storage Group directory list).

Deleting a Storage Group from the master backend deletes the group *and*
all directory list overrides on other hosts (i.e. you can't have a
directory list override if the group doesn't exist).

Therefore, you can go through each existing SG that you want to keep and
write down the directory list for each SG. Then, delete all the SGs
from the master. Then, you can simply define the SG's on the master and
add all the directories to them, as appropriate. With this approach,
you'll know for sure that you have things defined in the
most-maintainable way--once on the master backend, meaning there's only
one place to update the directory lists (that being on the master
backend). Since you won't have any overrides adding confusion, it will
be easy to see where the information is coming from.

Note, also, that some of the early SG code didn't clean things up this
way, so it's possible that you did all the steps properly in the past
with 0.21-fixes or something and it left garbage that's now causing
issues. Current 0.23-fixes will clean things up properly.

> The slave backend was my original master (and only) backend. The mysterious
> directory only showed up with version 0.22 or 0.23, also around the time that
> I switched master backend duties with my new file server (an ARM based QNAP
> NAS device). I may have originally and briefly used the mysterious storage
> directory when I was first testing mythtv, before I added a massive (for its
> day) 160 GB hard drive to hold recordings.
>
> Is it time to go digging in the database?

Ideally use the above approach.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mikep at randomtraveller

Jul 12, 2010, 10:20 AM

Post #8 of 15 (3015 views)
Permalink
Re: storage directories [In reply to]

Michael T. Dean wrote:
>
> Deleting a Storage Group from the master backend deletes the group *and* all
> directory list overrides on other hosts (i.e. you can't have a directory list
> override if the group doesn't exist).
>
> Therefore, you can go through each existing SG that you want to keep and
> write down the directory list for each SG. Then, delete all the SGs from the
> master. Then, you can simply define the SG's on the master and add all the
> directories to them, as appropriate. With this approach, you'll know for
> sure that you have things defined in the most-maintainable way--once on the
> master backend, meaning there's only one place to update the directory lists
> (that being on the master backend). Since you won't have any overrides adding
> confusion, it will be easy to see where the information is coming from.
>
Information, please. I'm slightly puzzled by how the above information is used.
If you're saying that you now only define SGs on the master back end - and in my
view that's the right place to do things like that - then how does a slave
backend find it's storage?

Two situations I can think of as examples, there may be other permutations.
Firstly, a slave with it's own storage. Does the MBE have to be able to access
the SBE storage location using samba/NFS/whatever in order to register the SG
directory?

Secondly, the reverse, a slave with no storage. Does it have to access storage
on the MBE (or somewhere else?) using samba/NFS/whatever or is all the
communication done using Myth's streaming protocol?

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


raymond at wagnerrp

Jul 12, 2010, 10:28 AM

Post #9 of 15 (3018 views)
Permalink
Re: storage directories [In reply to]

On 7/12/2010 13:20, Mike Perkins wrote:
> Information, please. I'm slightly puzzled by how the above information
> is used. If you're saying that you now only define SGs on the master
> back end - and in my view that's the right place to do things like
> that - then how does a slave backend find it's storage?

You define the storage where ever the storage is located. If you have
disks on the slave, you would define them on the slave. If you have no
disks on the slave, but instead have the master's disks mounted over
NFS, the slave will record to those NFS mounts.

> Secondly, the reverse, a slave with no storage. Does it have to access
> storage on the MBE (or somewhere else?) using samba/NFS/whatever or is
> all the communication done using Myth's streaming protocol?

All recording and transcoding currently requires direct file system access.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ylee at pobox

Jul 12, 2010, 1:47 PM

Post #10 of 15 (3009 views)
Permalink
Re: storage directories [In reply to]

Michael T. Dean <mtdean [at] thirdcontact> says:
> Unfortunately, the only (supported) way to get rid of directory
> overrides for no-longer-existing hosts is to use mythtv-setup on the
> master backend and actually delete the entire Storage Group
> (highlight the Storage Group name and hit D).

My current 0.23-fixes setup won't delete the storage group entry
("Default" in my case); it remains there. (As a test I was able to
delete and recreate the "Live TV" storage group.) I tried deleting the
directories inside the group first, too, with no change. Ideas?

--
MythTV FAQ Q: "Cheap frontend/backend?" A: Revo, $200-300 @ Newegg
Q: "Record HD cable/satellite?" A: Hauppauge HD-PVR, $200 @ Newegg
Q: "Can't change Live TV channels w/multirec!" A: Hit NEXTCARD key
More answers @ <URL:http://www.gossamer-threads.com/lists/mythtv/>
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jul 13, 2010, 10:00 AM

Post #11 of 15 (2985 views)
Permalink
Re: storage directories [In reply to]

On 07/12/2010 01:20 PM, Mike Perkins wrote:
> Michael T. Dean wrote:
>> Deleting a Storage Group from the master backend deletes the group
>> *and* all
>> directory list overrides on other hosts (i.e. you can't have a
>> directory list
>> override if the group doesn't exist).
>>
>> Therefore, you can go through each existing SG that you want to keep
>> and write down the directory list for each SG. Then, delete all the
>> SGs from the
>> master. Then, you can simply define the SG's on the master and add
>> all the
>> directories to them, as appropriate. With this approach, you'll know
>> for
>> sure that you have things defined in the most-maintainable way--once
>> on the
>> master backend, meaning there's only one place to update the
>> directory lists
>> (that being on the master backend). Since you won't have any
>> overrides adding
>> confusion, it will be easy to see where the information is coming from.
> Information, please. I'm slightly puzzled by how the above information
> is used. If you're saying that you now only define SGs on the master
> back end - and in my view that's the right place to do things like that

Yes. That's how 99.9999999999999999999999999999999999% of users should
do things. IMHO, the remaining fractional percent only needs to do
otherwise because they misconfigured their systems.

> - then how does a slave backend find it's storage?

A Storage Group is simply a mapping between a user-friendly name
("Default", "Movies", "Archive," ...) and a list of directory paths.
Note, also, that I did /not/ say anything about them containing
information about the host that contains those directories.

Therefore, when you *define* a Storage Group (which can only be done on
the master backend) and set up a list of directories, that Storage Group
exists on *all* hosts. Note, also, that I did not say that all the
directories in the directory list must exist on all the hosts--only that
the Storage Group exists on all hosts (the /mapping/ between a
user-friendly name and a list of directory paths exists on all hosts).

When you use mythtv-setup on any host other than the master backend to
edit Storage Groups, all you're doing is overriding the directory list
for an already-defined Storage Group--you're saying, "The list I gave on
the master backend is wrong." (So, really, you should just fix the list
on the master backend...)

> Two situations I can think of as examples, there may be other
> permutations. Firstly, a slave with it's own storage.

This is exactly the setup I have.

> Does the MBE have to be able to access the SBE storage location using
> samba/NFS/whatever in order to register the SG directory?

Nope. I never run NFS or Samba on my network. My master backend has 4
file systems it's using for recordings and my remote backend has 3 file
systems it's using for recordings. The master backend has no access to
the file systems on the remote backend and vice versa.

Regardless, I have *only* defined my Storage Groups on my master
backend. In my case, my Default Storage Group has a directory list:

/srv/mythtv/tv/a/recordings
/srv/mythtv/tv/b/recordings
/srv/mythtv/tv/c/recordings
/srv/mythtv/tv/d/recordings

where a, b, c, d are mount points and I've put my actual recordings into
subdirectories so that the backend(s) can tell if the file system is
mounted or not (otherwise, if I put a, b, c, d in the directory list, it
would write to the directory whether or not the file system is
mounted--meaning it would fill up the parent file system, which is my
root file system).

Note, also, as mentioned before, my master backend has 4 file systems
and my remote backend has only 3 file systems. This isn't a problem.
On my master backend, I have a different file system mounted at a, b, c,
and d. On my remote backend, I did not (yet--as I keep adding new
storage) mount a file system at d. Therefore, my remote backend has
directories:

/srv/mythtv/tv/a/recordings
/srv/mythtv/tv/b/recordings
/srv/mythtv/tv/c/recordings
/srv/mythtv/tv/d

Since there's no file system mounted at d, there's no
/srv/mythtv/tv/d/recordings (which is the one the Default storage group
uses), so MythTV sees that the directory doesn't exist and doesn't use
it (it simply ignores it) on my remote backend.

This means that I have no Storage Groups/Storage Group directory entries
defined for any host other than my master backend. (IMHO,) There's
absolutely no reason to ever touch Storage Groups on any host other than
the master backend.

If you prefer, you can do things slightly differently. Let's say you
don't want to "re-use" directory names on your different backends
because you may find it confusing to have 2 different file systems using
the same directory path. In that case, the Storage Group definition on
the master backend should contain the "union" of directory paths used by
all backends. So, it may have something like:

/srv/mythtv/tv/master/a/recordings
/srv/mythtv/tv/master/b/recordings
/srv/mythtv/tv/remote1/c/recordings
/srv/mythtv/tv/remote1/d/recordings

(where picking directory names is the hard part, but the above gives you
the idea). Again, a, b, c, d are all mount points and recordings is a
directory existing within the file system mounted there. Then, since
there's no /srv/mythtv/tv/master/a/recordings directory on the remote
backend, and no /srv/mythtv/tv/remote/c/recordings directory on the
master backend, MythTV will know to ignore those directories on the
hosts in question.

> Secondly, the reverse, a slave with no storage. Does it have to access
> storage on the MBE (or somewhere else?) using samba/NFS/whatever or is
> all the communication done using Myth's streaming protocol?

If you use NFS or Samba, you may have all your storage on the master
backend or some NAS or whatever. If so, just list all the directories
in the Storage Group definition on the master backend and other hosts
will use the same list of directories. Since all recording is done to
"local" file systems, the remote file systems must be mounted at the
same absolute path on all hosts.

The only time this approach of never overriding Storage Group directory
lists won't work is if you have your storage on different backends (as
in the above example with (/srv/mythtv/tv/master/a/recordings and
/srv/mythtv/tv/remote1/c/recordings--so each backend has its own hard
drives) and you NFS mount the TV directories on all hosts. With this
approach, your remote backend may write to
/srv/mythtv/tv/master/a/recordings across the network using NFS while
the master backend writes to /srv/mythtv/tv/remote1/c/recordings across
the network using NFS--which is extremely inefficient compared to having
each host write to its own local storage. This can be fixed by proper
choice of a Storage Group scheduler, but--IMHO--it's actually a
misconfiguration. There's no benefit to NFS-mounting TV directories on
remote (backend or frontend) systems if you don't want the host to
record to those directories. So, to fix it (properly ;), just don't NFS
mount your TV recordings directories on other hosts. Again, though, if
you feel you must have the TV directories NFS mounted on each MythTV
system, you can, but you need to choose an appropriate Storage Groups
scheduler.

So, basically, there's no need for any backend to have access to any
file system other than the file systems to which that backend records
TV. In other words, all MythTV recordings access (recording, playback,
etc.) is performed through the recording host's mythbackend. The only
exception is when you enable 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.

which is only meant to be used when you have a single file server
containing all file systems and you want to be able to stream/playback
recordings from remote backends even when the remote backends are shut
down or when *all* of your storage exists on the master backend and
remote backends record to it over the network--so without this setting,
streaming from the recording backend would mean the recording backend
reads a recording over NFS and then sends it across the network to the
frontend. Instead, enabling the override allows the master backend to
read it from local storage and send it across the network to the
frontend (so, only one trip across the network).

Moral of the story: Never, ever, ever, ever override a Storage Group
directory list. (In other words, *only* manage storage groups on the
master backend. Never even enter the Storage Directories section of
mythtv-setup on any host other than the master backend host.) This
makes your MythTV configuration, your understanding of which directories
each backend /might/ use, maintaining the list of directories in use,
adding new directories, removing directories, and life in (general) much
easier. :)

Quick Rules:
1) Only set Storage Group directory lists on the master backend. (Never
create Storage Group directory list overrides on the remote backends.)
2) Once properly configured (with no SG overrides on the remote
backends), only manage Storage Groups using mythtv-setup on the master
backend
3) Make the master backend's Storage Group directory list contain the
union of all directories on all hosts--whether those directories exist
on all hosts or not.
4) Directories in a Storage Group directory list need not exist on any
host (those that don't exist on a particular host are simply ignored).
5) If you don't want a directory used on a particular host make sure
that directory doesn't exist on that host.
6) Never put a mount point into a Storage Group directory list--always
put some subdirectory under the mount point so MythTV will know to
ignore the (non-existent) directory entry if the file system fails to
mount properly.
7) If you think you need to override a SG directory list on a remote
backend or remote frontend, you're making things more difficult than
they need to be.

Mike

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jul 13, 2010, 10:01 AM

Post #12 of 15 (2981 views)
Permalink
Re: storage directories [In reply to]

On 07/12/2010 04:47 PM, Yeechang Lee wrote:
> Michael T. Dean says:
>> Unfortunately, the only (supported) way to get rid of directory
>> overrides for no-longer-existing hosts is to use mythtv-setup on the
>> master backend and actually delete the entire Storage Group
>> (highlight the Storage Group name and hit D).
> My current 0.23-fixes setup won't delete the storage group entry
> ("Default" in my case); it remains there. (As a test I was able to
> delete and recreate the "Live TV" storage group.) I tried deleting the
> directories inside the group first, too, with no change. Ideas?

Right. The Default Storage Group is special. Users don't define it.
It /always/ exists because it's defined in code. If you fail to
configure any directories in the Default Storage Group.

That said, it should work /basically/ the way I described for the
general case. You go to mythtv-setup, then in Storage Directories, you
highlight the Default Storage Group, then hit your DELETE key (by
default D), and you'll see a pop-up that says, "Delete 'Default' Storage
Group? (from remote hosts)". When you say, "Yes, delete group," it will
delete the Default SG directory list overrides from your configuration.

However, as you mention, the Default Storage Group and the directory
list on the master backend will remain. If you want to edit the Default
Storage Group directory list on the master backend, you'll have to go
into it and then DELETE directory entries or add new ones. (We will
likely make it easier to delete all entries from the Default Storage
Group directory list defined on the master backend, but we decided it
wasn't worth the effort to fix up the old, dead-code, Qt-UI editor, but
should just do it when mythtv-setup is redone.)

Note that you may need to update to current 0.23-fixes. I don't
remember exactly when I fixed the editor to work more like we've now
learned it should work***, but it may have been after the 0.23 release
(or after the pre-release version various distros may ship). I can
guarantee it works properly in r25328 (as that's the one I have
installed, and I just verified it). However, it's been many months
since I fixed that, so some older versions will work, too.

/me notices some typos in the popups... Will have to fix those later.

Mike

***When SG's were first created, no one knew how they should be used
since no one had used them before. Now that we've had a couple of years
of experience with them, we understand how they should be used and have
adapted the Storage Group editor to work that way.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ylee at pobox

Jul 13, 2010, 7:07 PM

Post #13 of 15 (2960 views)
Permalink
Re: storage directories [In reply to]

Michael T. Dean <mtdean [at] thirdcontact> says:
> That said, it should work /basically/ the way I described for the
> general case. You go to mythtv-setup, then in Storage Directories,
> you highlight the Default Storage Group, then hit your DELETE key
> (by default D), and you'll see a pop-up that says, "Delete 'Default'
> Storage Group? (from remote hosts)". When you say, "Yes, delete
> group," it will delete the Default SG directory list overrides from
> your configuration.

Ah, the cleaning up of nonexisting hosts' directories still happens
even if the Default storage group doesn't actually go away? That's
what I wanted to do after reading your previous message.

--
MythTV FAQ Q: "Cheap frontend/backend?" A: Revo, $200-300 @ Newegg
Q: "Record HD cable/satellite?" A: Hauppauge HD-PVR, $200 @ Newegg
Q: "Can't change Live TV channels w/multirec!" A: Hit NEXTCARD key
More answers @ <URL:http://www.gossamer-threads.com/lists/mythtv/>
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mikep at randomtraveller

Jul 14, 2010, 6:15 AM

Post #14 of 15 (2957 views)
Permalink
Re: storage directories [In reply to]

Michael T. Dean wrote:
> On 07/12/2010 01:20 PM, Mike Perkins wrote:
>> Information, please. I'm slightly puzzled by how the above information
>> is used.
>
...Snipped long and excellent exposition on care, use and feeding of Storage
Groups...
>
Thanks, Mike. That's /exactly/ what I wanted to know.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


dbadia at gmail

Jul 21, 2010, 6:10 PM

Post #15 of 15 (2875 views)
Permalink
Re: storage directories [In reply to]

On Mon, Jul 12, 2010 at 1:28 PM, Raymond Wagner <raymond [at] wagnerrp> wrote:
> All recording and transcoding currently requires direct file system access.

I have 3 backends and use NFS mounts to expose all recording
directories to all backends. My master backend set to do all
commflagging in realtime. Commflaging requires NFS mounts to work, is
that correct?

Thanks for the info
Dave
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.