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

Mailing List Archive: MythTV: Users

Storage group question

 

 

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


gravityhammer at gmail

Nov 9, 2010, 6:20 PM

Post #1 of 24 (2548 views)
Permalink
Storage group question

I'm trying to set up a slave backend again (old one croaked). Before,
I was using .22, and shared my drives using NFS. Now, I'm going to
try to use Storage Groups.

I have mythbackend running on my slave backend (tunerless until my
HD-PVR comes in). I have three mount points for recordings:

/mnt/video1/recordings
/mnt/video2/recordings
/mnt/video3/recordings

I have added each of those directories on my master backend in the
"Default" storage group. When I exited mythtv-setup, it barked at me
that these directories didn't exist. No big deal, right, since my
slave backend wasn't running yet.

I started my master backend, and then the slave. The master backend
log shows the slave is connected. I go to the MythWeb status page,
though, and t doesn't show the drives. I check my frontend status -
no drives. I go to the backend webpage (IP:6544) and it shows the
drives.

Any suggestions on how to get this working?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 9, 2010, 6:57 PM

Post #2 of 24 (2513 views)
Permalink
Re: Storage group question [In reply to]

On 11/09/2010 09:20 PM, Phil Bridges wrote:
> I'm trying to set up a slave backend again (old one croaked). Before,
> I was using .22, and shared my drives using NFS. Now, I'm going to
> try to use Storage Groups.
>
> I have mythbackend running on my slave backend (tunerless until my
> HD-PVR comes in). I have three mount points for recordings:
>
> /mnt/video1/recordings
> /mnt/video2/recordings
> /mnt/video3/recordings
>
> I have added each of those directories on my master backend in the
> "Default" storage group. When I exited mythtv-setup, it barked at me
> that these directories didn't exist. No big deal, right, since my
> slave backend wasn't running yet.
>
> I started my master backend, and then the slave. The master backend
> log shows the slave is connected. I go to the MythWeb status page,
> though, and t doesn't show the drives. I check my frontend status -
> no drives. I go to the backend webpage (IP:6544) and it shows the
> drives.
>
> Any suggestions on how to get this working?

Look in the remote backend's logs for errors. Also, check your file
system permissions on those directories--they (and all their parent
directories) need read and execute for the user running mythbackend (and
the recordings directory needs write permissions).

If you don't see any errors, run the remote backend with:

mythbackend -v important,general,file

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


gravityhammer at gmail

Nov 9, 2010, 7:16 PM

Post #3 of 24 (2523 views)
Permalink
Re: Storage group question [In reply to]

On Tue, Nov 9, 2010 at 9:57 PM, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>  On 11/09/2010 09:20 PM, Phil Bridges wrote:
>>
>> I'm trying to set up a slave backend again (old one croaked).  Before,
>> I was using .22, and shared my drives using NFS.  Now, I'm going to
>> try to use Storage Groups.
>>
>> I have mythbackend running on my slave backend (tunerless until my
>> HD-PVR comes in).  I have three mount points for recordings:
>>
>> /mnt/video1/recordings
>> /mnt/video2/recordings
>> /mnt/video3/recordings
>>
>> I have added each of those directories on my master backend in the
>> "Default" storage group.  When I exited mythtv-setup, it barked at me
>> that these directories didn't exist.  No big deal, right, since my
>> slave backend wasn't running yet.
>>
>> I started my master backend, and then the slave.  The master backend
>> log shows the slave is connected.  I go to the MythWeb status page,
>> though, and t doesn't show the drives.  I check my frontend status -
>> no drives.  I go to the backend webpage (IP:6544) and it shows the
>> drives.
>>
>> Any suggestions on how to get this working?
>
> Look in the remote backend's logs for errors.  Also, check your file system
> permissions on those directories--they (and all their parent directories)
> need read and execute for the user running mythbackend (and the recordings
> directory needs write permissions).
>
> If you don't see any errors, run the remote backend with:
>
> mythbackend -v important,general,file
>

Nothing I see:

2010-11-09 22:12:46.399 mythbackend version:
branches/release-0-23-fixes [27077] www.mythtv.org
2010-11-09 22:12:46.399 (old)Settings::ReadSettings(settings.txt) - No such file
2010-11-09 22:12:46.399 Using runtime prefix = /usr
2010-11-09 22:12:46.399 Using configuration directory = /root/.mythtv
2010-11-09 22:12:46.399
(old)Settings::ReadSettings(/usr/share/mythtv/mysql.txt) - No such
file
2010-11-09 22:12:46.399
(old)Settings::ReadSettings(/usr/etc/mythtv/mysql.txt) - No such file
2010-11-09 22:12:46.400
(old)Settings::ReadSettings(/root/.mythtv/mysql.txt) - No such file
2010-11-09 22:12:46.400 (old)Settings::ReadSettings(./mysql.txt) - No such file
2010-11-09 22:12:46.400 Unable to read configuration file mysql.txt
2010-11-09 22:12:46.400 Empty LocalHostName.
2010-11-09 22:12:46.400 Using localhost value of slavebackend
2010-11-09 22:12:46.407 New DB connection, total: 1
2010-11-09 22:12:46.407 Unable to connect to database!
2010-11-09 22:12:46.407 Driver error was [1/2002]:
QMYSQL: Unable to connect
Database error was:
Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)


2010-11-09 22:12:46.960 UPnPautoconf() - Found one UPnP backend
2010-11-09 22:12:47.049 MythXMLClient::GetConnectionInfo Failed -
(604) No Security Pin assigned. Run mythtv-setup to set one.
2010-11-09 22:12:47.049 Testing network connectivity to '192.168.1.50'
2010-11-09 22:12:47.055 Closing DB connection named 'DBManager0'
2010-11-09 22:12:47.060 Connected to database 'mythconverg' at host:
192.168.1.50
2010-11-09 22:12:47.060 Closing DB connection named 'DBManager0'
2010-11-09 22:12:47.060 Deleting UPnP client...
2010-11-09 22:12:47.778 Connected to database 'mythconverg' at host:
192.168.1.50
2010-11-09 22:12:47.783 Using protocol version 23056
2010-11-09 22:12:47.920 Backend is running in EST5EDT time zone.
2010-11-09 22:12:47.940 Current MythTV Schema Version (DBSchemaVer): 1254
2010-11-09 22:12:47.942 MythBackend: Running as a slave backend.
2010-11-09 22:12:47.945 MythBackend, Error: No valid capture cards are
defined in the database.
Perhaps you should re-read the installation
instructions?
2010-11-09 22:12:47.947 New DB connection, total: 2
2010-11-09 22:12:47.948 Connected to database 'mythconverg' at host:
192.168.1.50
2010-11-09 22:12:47.948 New DB connection, total: 3
2010-11-09 22:12:47.949 Connected to database 'mythconverg' at host:
192.168.1.50
2010-11-09 22:12:48.266 Main::Registering HttpStatus Extension
2010-11-09 22:12:48.266 Enabled verbose msgs: important general file
2010-11-09 22:12:48.269 SG(): CheckAllStorageGroupDirs(): Checking All
Storage Group directories
2010-11-09 22:12:49.271 Connecting to master server: 192.168.1.50:6543
2010-11-09 22:12:49.272 Connected successfully
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 9, 2010, 8:06 PM

Post #4 of 24 (2513 views)
Permalink
Re: Storage group question [In reply to]

On 11/09/2010 10:16 PM, Phil Bridges wrote:
> On Tue, Nov 9, 2010 at 9:57 PM, Michael T. Dean wrote:
>> On 11/09/2010 09:20 PM, Phil Bridges wrote:
>>> I'm trying to set up a slave backend again (old one croaked). Before,
>>> I was using .22, and shared my drives using NFS. Now, I'm going to
>>> try to use Storage Groups.
>>>
>>> I have mythbackend running on my slave backend (tunerless until my
>>> HD-PVR comes in). I have three mount points for recordings:
>>>
>>> /mnt/video1/recordings
>>> /mnt/video2/recordings
>>> /mnt/video3/recordings
>>>
>>> I have added each of those directories on my master backend in the
>>> "Default" storage group. When I exited mythtv-setup, it barked at me
>>> that these directories didn't exist. No big deal, right, since my
>>> slave backend wasn't running yet.
>>>
>>> I started my master backend, and then the slave. The master backend
>>> log shows the slave is connected. I go to the MythWeb status page,
>>> though, and t doesn't show the drives. I check my frontend status -
>>> no drives. I go to the backend webpage (IP:6544) and it shows the
>>> drives.
>>>
>>> Any suggestions on how to get this working?
>> Look in the remote backend's logs for errors. Also, check your file system
>> permissions on those directories--they (and all their parent directories)
>> need read and execute for the user running mythbackend (and the recordings
>> directory needs write permissions).
>>
>> If you don't see any errors, run the remote backend with:
>>
>> mythbackend -v important,general,file
> Nothing I see:
...
> 2010-11-09 22:12:47.942 MythBackend: Running as a slave backend.
> 2010-11-09 22:12:47.945 MythBackend, Error: No valid capture cards are
> defined in the database.
> Perhaps you should re-read the installation
> instructions?

There's your problem. Once you have your capture cards defined, it will
work.

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


gravityhammer at gmail

Nov 9, 2010, 8:12 PM

Post #5 of 24 (2513 views)
Permalink
Re: Storage group question [In reply to]

On Tue, Nov 9, 2010 at 11:06 PM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
>  On 11/09/2010 10:16 PM, Phil Bridges wrote:
>>
>> On Tue, Nov 9, 2010 at 9:57 PM, Michael T. Dean wrote:
>>>
>>>  On 11/09/2010 09:20 PM, Phil Bridges wrote:
>>>>
>>>> I'm trying to set up a slave backend again (old one croaked).  Before,
>>>> I was using .22, and shared my drives using NFS.  Now, I'm going to
>>>> try to use Storage Groups.
>>>>
>>>> I have mythbackend running on my slave backend (tunerless until my
>>>> HD-PVR comes in).  I have three mount points for recordings:
>>>>
>>>> /mnt/video1/recordings
>>>> /mnt/video2/recordings
>>>> /mnt/video3/recordings
>>>>
>>>> I have added each of those directories on my master backend in the
>>>> "Default" storage group.  When I exited mythtv-setup, it barked at me
>>>> that these directories didn't exist.  No big deal, right, since my
>>>> slave backend wasn't running yet.
>>>>
>>>> I started my master backend, and then the slave.  The master backend
>>>> log shows the slave is connected.  I go to the MythWeb status page,
>>>> though, and t doesn't show the drives.  I check my frontend status -
>>>> no drives.  I go to the backend webpage (IP:6544) and it shows the
>>>> drives.
>>>>
>>>> Any suggestions on how to get this working?
>>>
>>> Look in the remote backend's logs for errors.  Also, check your file
>>> system
>>> permissions on those directories--they (and all their parent directories)
>>> need read and execute for the user running mythbackend (and the
>>> recordings
>>> directory needs write permissions).
>>>
>>> If you don't see any errors, run the remote backend with:
>>>
>>> mythbackend -v important,general,file
>>
>> Nothing I see:
>
> ...
>>
>> 2010-11-09 22:12:47.942 MythBackend: Running as a slave backend.
>> 2010-11-09 22:12:47.945 MythBackend, Error: No valid capture cards are
>> defined in the database.
>>                         Perhaps you should re-read the installation
>> instructions?
>
> There's your problem.  Once you have your capture cards defined, it will
> work.
>

Huh. Capture cards are required for storage groups to work on a slave
backend? Looks like something for the wiki.

Looks like it's back to NFS for me for now, then - not sure when my
HD-PVR will be here, and I need to use the space.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


gravityhammer at gmail

Nov 11, 2010, 7:36 PM

Post #6 of 24 (2479 views)
Permalink
Re: Storage group question [In reply to]

On Tue, Nov 9, 2010 at 11:12 PM, Phil Bridges <gravityhammer [at] gmail> wrote:
> On Tue, Nov 9, 2010 at 11:06 PM, Michael T. Dean
> <mtdean [at] thirdcontact> wrote:
>>  On 11/09/2010 10:16 PM, Phil Bridges wrote:
>>>
>>> On Tue, Nov 9, 2010 at 9:57 PM, Michael T. Dean wrote:
>>>>
>>>>  On 11/09/2010 09:20 PM, Phil Bridges wrote:
>>>>>
>>>>> I'm trying to set up a slave backend again (old one croaked).  Before,
>>>>> I was using .22, and shared my drives using NFS.  Now, I'm going to
>>>>> try to use Storage Groups.
>>>>>
>>>>> I have mythbackend running on my slave backend (tunerless until my
>>>>> HD-PVR comes in).  I have three mount points for recordings:
>>>>>
>>>>> /mnt/video1/recordings
>>>>> /mnt/video2/recordings
>>>>> /mnt/video3/recordings
>>>>>
>>>>> I have added each of those directories on my master backend in the
>>>>> "Default" storage group.  When I exited mythtv-setup, it barked at me
>>>>> that these directories didn't exist.  No big deal, right, since my
>>>>> slave backend wasn't running yet.
>>>>>
>>>>> I started my master backend, and then the slave.  The master backend
>>>>> log shows the slave is connected.  I go to the MythWeb status page,
>>>>> though, and t doesn't show the drives.  I check my frontend status -
>>>>> no drives.  I go to the backend webpage (IP:6544) and it shows the
>>>>> drives.
>>>>>
>>>>> Any suggestions on how to get this working?
>>>>
>>>> Look in the remote backend's logs for errors.  Also, check your file
>>>> system
>>>> permissions on those directories--they (and all their parent directories)
>>>> need read and execute for the user running mythbackend (and the
>>>> recordings
>>>> directory needs write permissions).
>>>>
>>>> If you don't see any errors, run the remote backend with:
>>>>
>>>> mythbackend -v important,general,file
>>>
>>> Nothing I see:
>>
>> ...
>>>
>>> 2010-11-09 22:12:47.942 MythBackend: Running as a slave backend.
>>> 2010-11-09 22:12:47.945 MythBackend, Error: No valid capture cards are
>>> defined in the database.
>>>                         Perhaps you should re-read the installation
>>> instructions?
>>
>> There's your problem.  Once you have your capture cards defined, it will
>> work.
>>
>
> Huh.  Capture cards are required for storage groups to work on a slave
> backend?  Looks like something for the wiki.
>
> Looks like it's back to NFS for me for now, then - not sure when my
> HD-PVR will be here, and I need to use the space.
>

OK - I have my tuner set up on my slave backend. Recordings made on
that tuner record fine on the slave backend. Unfortunately, though,
when I have a recording from a tuner on my master backend, it can't
record onto the slave backend.

In my master backend's default storage group, I have the following directories:

/mnt/master/recordings
/mnt/master/recordings2
/mnt/video1/recordings
/mnt/video2/recordings
/mnt/video3/recordings

The last three are directories that exist only on my slave backend.
All of these slave directories are set at 777.

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


cpinkham at bc2va

Nov 11, 2010, 8:34 PM

Post #7 of 24 (2471 views)
Permalink
Re: Storage group question [In reply to]

* On Thu Nov 11, 2010 at 10:36:43PM -0500, Phil Bridges wrote:
> OK - I have my tuner set up on my slave backend. Recordings made on
> that tuner record fine on the slave backend. Unfortunately, though,
> when I have a recording from a tuner on my master backend, it can't
> record onto the slave backend.

I think you're misunderstanding the concept of Storage Groups a little.
Storage Groups do not allow one backend to record across the network
to another backend's hard disks. If you want to do this, you'll still
have to use NFS. Several of us have discussed letting one backend
write across the network to another backends drives via MythTV's internal
protocol, but we haven't implemented the functionality. Most of the
parts are there because of other features, it would just need some glue.

> All of these slave directories are set at 777.
>
> Any suggestions?

If you want the master to record to the slave's directories, the master will
need to be able to mount those over NFS. If you cross-mount your directories
on the opposite servers, the storage scheduling code will look at all 5 drives
and schedule recordings across them based on the storage scheduling setting
you have chosen.

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


gravityhammer at gmail

Nov 11, 2010, 8:43 PM

Post #8 of 24 (2476 views)
Permalink
Re: Storage group question [In reply to]

On Thu, Nov 11, 2010 at 11:34 PM, Chris Pinkham <cpinkham [at] bc2va> wrote:
> * On Thu Nov 11, 2010 at 10:36:43PM -0500, Phil Bridges wrote:
>> OK - I have my tuner set up on my slave backend.  Recordings made on
>> that tuner record fine on the slave backend.  Unfortunately, though,
>> when I have a recording from a tuner on my master backend, it can't
>> record onto the slave backend.
>
> I think you're misunderstanding the concept of Storage Groups a little.
> Storage Groups do not allow one backend to record across the network
> to another backend's hard disks.  If you want to do this, you'll still
> have to use NFS.  Several of us have discussed letting one backend
> write across the network to another backends drives via MythTV's internal
> protocol, but we haven't implemented the functionality.  Most of the
> parts are there because of other features, it would just need some glue.
>
>> All of these slave directories are set at 777.
>>
>> Any suggestions?
>
> If you want the master to record to the slave's directories, the master will
> need to be able to mount those over NFS.  If you cross-mount your directories
> on the opposite servers, the storage scheduling code will look at all 5 drives
> and schedule recordings across them based on the storage scheduling setting
> you have chosen.
>

Yeah - that's the weird thing. I didn't expect it to try to record to
the slave backend, but it was trying anyway.

I'm not sure what was going, but a restart seems to have solved it.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


gravityhammer at gmail

Nov 14, 2010, 4:15 AM

Post #9 of 24 (2428 views)
Permalink
Re: Storage group question [In reply to]

On Thu, Nov 11, 2010 at 11:43 PM, Phil Bridges <gravityhammer [at] gmail> wrote:
> On Thu, Nov 11, 2010 at 11:34 PM, Chris Pinkham <cpinkham [at] bc2va> wrote:
>> * On Thu Nov 11, 2010 at 10:36:43PM -0500, Phil Bridges wrote:
>>> OK - I have my tuner set up on my slave backend.  Recordings made on
>>> that tuner record fine on the slave backend.  Unfortunately, though,
>>> when I have a recording from a tuner on my master backend, it can't
>>> record onto the slave backend.
>>
>> I think you're misunderstanding the concept of Storage Groups a little.
>> Storage Groups do not allow one backend to record across the network
>> to another backend's hard disks.  If you want to do this, you'll still
>> have to use NFS.  Several of us have discussed letting one backend
>> write across the network to another backends drives via MythTV's internal
>> protocol, but we haven't implemented the functionality.  Most of the
>> parts are there because of other features, it would just need some glue.
>>
>>> All of these slave directories are set at 777.
>>>
>>> Any suggestions?
>>
>> If you want the master to record to the slave's directories, the master will
>> need to be able to mount those over NFS.  If you cross-mount your directories
>> on the opposite servers, the storage scheduling code will look at all 5 drives
>> and schedule recordings across them based on the storage scheduling setting
>> you have chosen.
>>
>
> Yeah - that's the weird thing.  I didn't expect it to try to record to
> the slave backend, but it was trying anyway.
>
> I'm not sure what was going, but a restart seems to have solved it.
>

I thought it resolved it, but it didn't. Here's some of my log from
this morning from the master backend:


2010-11-14 05:59:29.882 TVRec(1): ASK_RECORDING 1 29 0 0
2010-11-14 05:59:29.978 TVRec(4): ASK_RECORDING 4 29 0 0
2010-11-14 05:59:30.410 TVRec(5): ASK_RECORDING 5 29 0 0
2010-11-14 06:00:01.814 MainServer::ANN Monitor
2010-11-14 06:00:01.815 adding: strongsad as a client (events: 0)
2010-11-14 06:00:02.180 ProgramInfo(3130_20101114020000.mpg), Error:
GetPlaybackURL: '3130_20101114020000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:02.182 ProgramInfo(3130_20101114030000.mpg), Error:
GetPlaybackURL: '3130_20101114030000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:02.819 ProgramInfo(): Updated pathname '':'' ->
'1082_20101114060000.mpg'
2010-11-14 06:00:02.856 TVRec(1): Changing from None to RecordingOnly
2010-11-14 06:00:02.857 TVRec(1): HW Tuner: 1->1
2010-11-14 06:00:02.904 AutoExpire: CalcParams(): Max required Free
Space: 3.0 GB w/freq: 14 min
2010-11-14 06:00:02.905 Started recording: Sesame Street "The Shoe
Fairy": channel 1082 on cardid 1, sourceid 1
2010-11-14 06:00:02.936 ProgramInfo(): Updated pathname '':'' ->
'1082_20101114060000.mpg'
2010-11-14 06:00:03.012 ProgramInfo(3130_20101114020000.mpg), Error:
GetPlaybackURL: '3130_20101114020000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:03.014 ProgramInfo(3130_20101114030000.mpg), Error:
GetPlaybackURL: '3130_20101114030000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:03.017 ProgramInfo(1082_20101114060000.mpg), Error:
GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:03.239 ProgramInfo(1082_20101114060000.mpg), Error:
GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:03.425 ProgramInfo(1082_20101114060000.mpg), Error:
GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
not be found.
2010-11-14 06:00:03.571 TVRec(1): rec->GetFileName():
'/mnt/video3/recordings/1082_20101114060000.mpg'
2010-11-14 06:00:03.572 TFW, Error: Opening file
'/mnt/video3/recordings/1082_20101114060000.mpg'.
eno: No such file or directory (2)
2010-11-14 06:00:03.573 TVRec(1) Error: RingBuffer
'/mnt/video3/recordings/1082_20101114060000.mpg' not open...
2010-11-14 06:00:03.574 TVRec(1): Changing from RecordingOnly to None
2010-11-14 06:00:03.576 ProgramInfo(): Updated pathname '':'' ->
'1082_20101114060000.mpg'
2010-11-14 06:00:03.577 Finished recording Sesame Street "The Shoe
Fairy": channel 1082

This is the master backend's log. Inputs 1-7 are on the master
backend - input 9 is on the slave. /mnt/video3/recordings is one of
my three slave backend mount points. Why in the world would the
master backend try to write to it?

Looks like I may just have to NFS mount all of the slave drives on the
master. How does this affect my storage group setup? Should I also
mount all of my master backend drives on the slave?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bobnvic at gmail

Nov 15, 2010, 11:34 AM

Post #10 of 24 (2416 views)
Permalink
Re: Storage group question [In reply to]

On Sun, Nov 14, 2010 at 6:15 AM, Phil Bridges <gravityhammer [at] gmail> wrote:
> On Thu, Nov 11, 2010 at 11:43 PM, Phil Bridges <gravityhammer [at] gmail> wrote:
>> On Thu, Nov 11, 2010 at 11:34 PM, Chris Pinkham <cpinkham [at] bc2va> wrote:
>>> * On Thu Nov 11, 2010 at 10:36:43PM -0500, Phil Bridges wrote:
>>>> OK - I have my tuner set up on my slave backend.  Recordings made on
>>>> that tuner record fine on the slave backend.  Unfortunately, though,
>>>> when I have a recording from a tuner on my master backend, it can't
>>>> record onto the slave backend.
snip
>> Yeah - that's the weird thing.  I didn't expect it to try to record to
>> the slave backend, but it was trying anyway.
>>
>> I'm not sure what was going, but a restart seems to have solved it.
>>
>
> I thought it resolved it, but it didn't.  Here's some of my log from
> this morning from the master backend:
>
>
> 2010-11-14 05:59:29.882 TVRec(1): ASK_RECORDING 1 29 0 0
> 2010-11-14 05:59:29.978 TVRec(4): ASK_RECORDING 4 29 0 0
> 2010-11-14 05:59:30.410 TVRec(5): ASK_RECORDING 5 29 0 0
> 2010-11-14 06:00:01.814 MainServer::ANN Monitor
> 2010-11-14 06:00:01.815 adding: strongsad as a client (events: 0)
> 2010-11-14 06:00:02.180 ProgramInfo(3130_20101114020000.mpg), Error:
> GetPlaybackURL: '3130_20101114020000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:02.182 ProgramInfo(3130_20101114030000.mpg), Error:
> GetPlaybackURL: '3130_20101114030000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:02.819 ProgramInfo(): Updated pathname '':'' ->
> '1082_20101114060000.mpg'
> 2010-11-14 06:00:02.856 TVRec(1): Changing from None to RecordingOnly
> 2010-11-14 06:00:02.857 TVRec(1): HW Tuner: 1->1
> 2010-11-14 06:00:02.904 AutoExpire: CalcParams(): Max required Free
> Space: 3.0 GB w/freq: 14 min
> 2010-11-14 06:00:02.905 Started recording: Sesame Street "The Shoe
> Fairy": channel 1082 on cardid 1, sourceid 1
> 2010-11-14 06:00:02.936 ProgramInfo(): Updated pathname '':'' ->
> '1082_20101114060000.mpg'
> 2010-11-14 06:00:03.012 ProgramInfo(3130_20101114020000.mpg), Error:
> GetPlaybackURL: '3130_20101114020000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:03.014 ProgramInfo(3130_20101114030000.mpg), Error:
> GetPlaybackURL: '3130_20101114030000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:03.017 ProgramInfo(1082_20101114060000.mpg), Error:
> GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:03.239 ProgramInfo(1082_20101114060000.mpg), Error:
> GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:03.425 ProgramInfo(1082_20101114060000.mpg), Error:
> GetPlaybackURL: '1082_20101114060000.mpg' should be local, but it can
> not be found.
> 2010-11-14 06:00:03.571 TVRec(1): rec->GetFileName():
> '/mnt/video3/recordings/1082_20101114060000.mpg'
> 2010-11-14 06:00:03.572 TFW, Error: Opening file
> '/mnt/video3/recordings/1082_20101114060000.mpg'.
>                        eno: No such file or directory (2)
> 2010-11-14 06:00:03.573 TVRec(1) Error: RingBuffer
> '/mnt/video3/recordings/1082_20101114060000.mpg' not open...
> 2010-11-14 06:00:03.574 TVRec(1): Changing from RecordingOnly to None
> 2010-11-14 06:00:03.576 ProgramInfo(): Updated pathname '':'' ->
> '1082_20101114060000.mpg'
> 2010-11-14 06:00:03.577 Finished recording Sesame Street "The Shoe
> Fairy": channel 1082
>
> This is the master backend's log.  Inputs 1-7 are on the master
> backend - input 9 is on the slave.  /mnt/video3/recordings is one of
> my three slave backend mount points.  Why in the world would the
> master backend try to write to it?
>
> Looks like I may just have to NFS mount all of the slave drives on the
> master.  How does this affect my storage group setup?  Should I also
> mount all of my master backend drives on the slave?

I'm getting the errors. The master only tries to record to the
non-existant directories (for the master) when the slave is connected.
I haven't been able to run the slave backend under .24 because of
this.

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


greg12866 at nycap

May 7, 2012, 9:21 AM

Post #11 of 24 (2079 views)
Permalink
Re: Storage group question [In reply to]

On 05/07/2012 11:48 AM, Martin Moores wrote:
> On 7 May 2012 16:44, Greg <greg12866 [at] nycap
> <mailto:greg12866 [at] nycap>> wrote:
>
> I have a lot of TV series ripped to my hard drives.. They are spread
> over 6 hard drives... They are each in their own folders like this,
> Star Trek/Season 1/ name of episode.... I have central folder called
> TV_Series and all the TV series are linked using symbolic
> links....This way they are all presented under one menu sorted in
> alphabetical order... I recently read where this isn't the proper
> way to do this...My question is how would I get the same results
> using a different scheme?
>
>
> Create the same file structure on each hard drive, "TV_Series" for
> example. Then, in mythtv setup, add each of these drives as a storage
> group under Videos. As long as the folder structures match on each
> drive, myth will combine them and show them in the frontend as one
> single storage area.
>
> Martin
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
Thanks, I will give that a go...
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jam at tigger

May 8, 2012, 5:02 PM

Post #12 of 24 (2060 views)
Permalink
Re: Storage group question [In reply to]

On 08/05/2012, at 1:27 AM, mythtv-users-request [at] mythtv wrote:

>> I have a lot of TV series ripped to my hard drives.. They are spread over
>> 6 hard drives... They are each in their own folders like this, Star
>> Trek/Season 1/ name of episode.... I have central folder called TV_Series
>> and all the TV series are linked using symbolic links....This way they are
>> all presented under one menu sorted in alphabetical order... I recently
>> read where this isn't the proper way to do this...My question is how would
>> I get the same results using a different scheme?
>>
>>
> Create the same file structure on each hard drive, "TV_Series" for
> example. Then, in mythtv setup, add each of these drives as a storage
> group under Videos. As long as the folder structures match on each drive,
> myth will combine them and show them in the frontend as one single storage
> area.

Guys it sounds awefuly like you don't know how mount works

say /mnt/store ...
mount /dev/sdb1 /mnt/store/group1
mount /dev/sdc1 /mnt/store/group2
etc
ie each disc is mounted in the storage tree at the 'right spot'

all done automatically with entries in /etc/fstab
GUI tools depending on your distro eg yast for SuSE

Because this statement is garbage: <Create the same file structure on each hard drive>

Spend some time reading and digesting 'mount'
Also consider my soapbox 'Seagate: ATA more than an interface ...' which argues that having more than a single consumer drive in a box will cause disk failures.
YMMV but the logic is impecable and tales of woe abound.

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


michael at thewatsonfamily

May 8, 2012, 6:23 PM

Post #13 of 24 (2065 views)
Permalink
Re: Storage group question [In reply to]

On 9/05/2012 10:02 AM, James Linder wrote:
> On 08/05/2012, at 1:27 AM, mythtv-users-request [at] mythtv wrote:
>
>>> I have a lot of TV series ripped to my hard drives.. They are spread over
>>> 6 hard drives... They are each in their own folders like this, Star
>>> Trek/Season 1/ name of episode.... I have central folder called TV_Series
>>> and all the TV series are linked using symbolic links....This way they are
>>> all presented under one menu sorted in alphabetical order... I recently
>>> read where this isn't the proper way to do this...My question is how would
>>> I get the same results using a different scheme?
>>>
>>>
>> Create the same file structure on each hard drive, "TV_Series" for
>> example. Then, in mythtv setup, add each of these drives as a storage
>> group under Videos. As long as the folder structures match on each drive,
>> myth will combine them and show them in the frontend as one single storage
>> area.
> Guys it sounds awefuly like you don't know how mount works
>
> say /mnt/store ...
> mount /dev/sdb1 /mnt/store/group1
> mount /dev/sdc1 /mnt/store/group2
> etc
> ie each disc is mounted in the storage tree at the 'right spot'
>
> all done automatically with entries in /etc/fstab
> GUI tools depending on your distro eg yast for SuSE
>
> Because this statement is garbage:<Create the same file structure on each hard drive>
>
> Spend some time reading and digesting 'mount'
> Also consider my soapbox 'Seagate: ATA more than an interface ...' which argues that having more than a single consumer drive in a box will cause disk failures.
What utter shite. Simple marketing ploy to convince the naive to invest
in more expensive server grade hardware. Whilst there are benefits to
server grade drives not worth the extra $$$ for a myth setup.
> YMMV but the logic is impecable and tales of woe abound.
>
> James
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2171 / Virus Database: 2425/4986 - Release Date: 05/08/12

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


moores.martin at gmail

May 9, 2012, 12:56 AM

Post #14 of 24 (2056 views)
Permalink
Re: Storage group question [In reply to]

On 9 May 2012 01:02, James Linder <jam [at] tigger> wrote:

>
> Because this statement is garbage: <Create the same file structure on each
> hard drive>
>
>
How so?

I understand mount thanks.

If Greg has 6 hard drives, each with a folder called "TV_Series", he may
have other folders "Films", "Home Video", "Whatever". To get those to show
in a single view using storage directories, then the same folder structure
need to be created on each hard drive (or whichever root directory is being
used for the storage directory), regardless of where/how the drives are
mounted.

Using your method (and presumably using /mnt/store as the storage directory
path), mythfrontend would just show 6 "group" folders, each with
"TV_Series" inside, which would not solve anything.

Martin


mtdean at thirdcontact

Jan 13, 2013, 4:05 PM

Post #15 of 24 (1773 views)
Permalink
Re: Storage group question [In reply to]

On 01/13/2013 06:51 PM, Paul Stillwell wrote:
> If I have a recording rule set up to record to a specific Storage Group (e.g. LiveTV) and the specified storage group fills up, what will happen? Will a scheduled recording be ignored or will a recording be deleted in that storage group and the new recording be put in there? Or something else?
>

When a file system fills up and MythTV chooses to use that file system
(note that this is at a level /beneath/ Storage Groups), it will attempt
to delete an existing recording from that file system while it's
recording the new show. When it deletes a recording, it does so by
using the auto-expiration method you've configured. For all users, the
first shows expired will be not-in-progress Live TV recordings (i.e.
those recordings of already-ended shows or show pieces that were
partially recorded, but have "ended" because the user exited Live TV or
changed channels in Live TV), then Deleted recordings (recordings in the
Deleted recording group), then other recordings for which "Allow
auto-expiration" is enabled. If you have no recordings that allow
expiration (and MythTV has already deleted, or you don't have any, Live
TV or Deleted shows), MythTV will just write data until the kernel stops
it, at which point Bad Things Happen...

So, important points are:

a) Storage Groups are not necessarily related to file systems. You may
have a Storage Group, such as Default, that contains multiple
directories (such as /srv/mythtv/tv/a/recordings and
/srv/mythtv/tv/b/recordings, where /srv/mythtv/tv/a and /srv/mythtv/tv/b
are mount points for 2 separate file systems on 2 separate disks).
b) MythTV will only expire shows from file systems that are in use.
c) MythTV chooses which directory/file system to use based on the
Storage Group Disk Scheduler you've specified (
http://www.mythtv.org/wiki/Storage_Groups#Storage_Group_Disk_Scheduler ).

So, If the file system at /srv/mythtv/tv/b is full, and MythTV is told
to write to the Default Storage Group, but chooses to use
/srv/mythtv/tv/a/recordings, then no recordings will be expired.
However, if another recording starts and MythTV chooses to use
/srv/mythtv/tv/b/recordings (the full file system), it will need to
expire Live TV or Deleted recordings or other recordings to make room
for the new recording.

Also, if you have any full file systems--i.e. if you plan to let
auto-expiration remove files, you almost definitely should not use the
Balanced Free Space Storage Group Scheduler. You'd be better off with
the Balanced Disk I/O or the Combination Storage Group Disk Scheduler.

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


bigboi at wackywombats

Jan 14, 2013, 7:15 AM

Post #16 of 24 (1768 views)
Permalink
Re: Storage group question [In reply to]

On Jan 13, 2013, at 4:05 PM, Michael T. Dean wrote:

> On 01/13/2013 06:51 PM, Paul Stillwell wrote:
>> If I have a recording rule set up to record to a specific Storage Group (e.g. LiveTV) and the specified storage group fills up, what will happen? Will a scheduled recording be ignored or will a recording be deleted in that storage group and the new recording be put in there? Or something else?
>>
>
> When a file system fills up and MythTV chooses to use that file system (note that this is at a level /beneath/ Storage Groups), it will attempt to delete an existing recording from that file system while it's recording the new show. When it deletes a recording, it does so by using the auto-expiration method you've configured. For all users, the first shows expired will be not-in-progress Live TV recordings (i.e. those recordings of already-ended shows or show pieces that were partially recorded, but have "ended" because the user exited Live TV or changed channels in Live TV), then Deleted recordings (recordings in the Deleted recording group), then other recordings for which "Allow auto-expiration" is enabled. If you have no recordings that allow expiration (and MythTV has already deleted, or you don't have any, Live TV or Deleted shows), MythTV will just write data until the kernel stops it, at which point Bad Things Happen...
>
> So, important points are:
>
> a) Storage Groups are not necessarily related to file systems. You may have a Storage Group, such as Default, that contains multiple directories (such as /srv/mythtv/tv/a/recordings and /srv/mythtv/tv/b/recordings, where /srv/mythtv/tv/a and /srv/mythtv/tv/b are mount points for 2 separate file systems on 2 separate disks).
> b) MythTV will only expire shows from file systems that are in use.
> c) MythTV chooses which directory/file system to use based on the Storage Group Disk Scheduler you've specified ( http://www.mythtv.org/wiki/Storage_Groups#Storage_Group_Disk_Scheduler ).
>
> So, If the file system at /srv/mythtv/tv/b is full, and MythTV is told to write to the Default Storage Group, but chooses to use /srv/mythtv/tv/a/recordings, then no recordings will be expired. However, if another recording starts and MythTV chooses to use /srv/mythtv/tv/b/recordings (the full file system), it will need to expire Live TV or Deleted recordings or other recordings to make room for the new recording.
>
> Also, if you have any full file systems--i.e. if you plan to let auto-expiration remove files, you almost definitely should not use the Balanced Free Space Storage Group Scheduler. You'd be better off with the Balanced Disk I/O or the Combination Storage Group Disk Scheduler.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

OK, that's what I thought would happen. A related question: Can the same directory be mapped into multiple Storage groups? For example, if I have 3 directories for recordings like this:

/srv/mythtv/a/recordings
/srv/mythtv/b/recordings
/srv/mythtv/c/recordings

Mapped to the following Storage Groups like this:

Default: /srv/mythtv/a/recordings, /srv/mythtv/b/recordings
Sports: /srv/mythtv/c/recordings, /srv/mythtv/a/recordings

Will that be ok? I'm trying to come up with a scheme such that the small space I have on /srv/mythtv/c/recordings that I want to use when I record sports will be safe if I accidentally fill that drive up and some other sports show is going to record.

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


joe at thefrys

Jan 14, 2013, 7:29 AM

Post #17 of 24 (1761 views)
Permalink
Re: Storage group question [In reply to]

>
>
> OK, that's what I thought would happen. A related question: Can the same
> directory be mapped into multiple Storage groups? For example, if I have 3
> directories for recordings like this:
>
> /srv/mythtv/a/recordings
> /srv/mythtv/b/recordings
> /srv/mythtv/c/recordings
>
> Mapped to the following Storage Groups like this:
>
> Default: /srv/mythtv/a/recordings, /srv/mythtv/b/recordings
> Sports: /srv/mythtv/c/recordings, /srv/mythtv/a/recordings
>
> Will that be ok? I'm trying to come up with a scheme such that the small
> space I have on /srv/mythtv/c/recordings that I want to use when I record
> sports will be safe if I accidentally fill that drive up and some other
> sports show is going to record.
>

Yes, the same path can be entered in multiple storage group definitions,
though I see little reason to assign the same paths to two storage groups,
at that point you could get away with just one. If your goal is a bit
more complex, you will want to keep in mind that mythtv has multiple
methods for balancing the load/storage of recordings within the storage
groups, you will want to select the one that makes the most sense to your
goals.


joe at thefrys

Jan 14, 2013, 7:34 AM

Post #18 of 24 (1764 views)
Permalink
Re: Storage group question [In reply to]

>
>
>> OK, that's what I thought would happen. A related question: Can the same
>> directory be mapped into multiple Storage groups? For example, if I have 3
>> directories for recordings like this:
>>
>> /srv/mythtv/a/recordings
>> /srv/mythtv/b/recordings
>> /srv/mythtv/c/recordings
>>
>> Mapped to the following Storage Groups like this:
>>
>> Default: /srv/mythtv/a/recordings, /srv/mythtv/b/recordings
>> Sports: /srv/mythtv/c/recordings, /srv/mythtv/a/recordings
>>
>> Will that be ok? I'm trying to come up with a scheme such that the small
>> space I have on /srv/mythtv/c/recordings that I want to use when I record
>> sports will be safe if I accidentally fill that drive up and some other
>> sports show is going to record.
>>
>
> Yes, the same path can be entered in multiple storage group definitions,
> though I see little reason to assign the same paths to two storage groups,
> at that point you could get away with just one. If your goal is a bit
> more complex, you will want to keep in mind that mythtv has multiple
> methods for balancing the load/storage of recordings within the storage
> groups, you will want to select the one that makes the most sense to your
> goals.
>

Oh, and if two storage groups contain the same path... I'm not exactly sure
if mythtv will properly report the storage group for the individual
recordings. For example if both the 'default' and 'sports' storage groups
share a particular folder, you may find that the recordings to the 'sports'
storage group will report that they are in the 'default' storage group. I
know that mythtv will allow recordings to be moved around the file system,
thus between storage groups, so I suspect that it will detect all
recordings in a particular folder as being part of just one storage group;
not both.


mtdean at thirdcontact

Jan 14, 2013, 7:44 AM

Post #19 of 24 (1761 views)
Permalink
Re: Storage group question [In reply to]

On 01/14/2013 10:15 AM, Paul Stillwell wrote:
> A related question: Can the same directory be mapped into multiple Storage groups? For example, if I have 3 directories for recordings like this:
>
> /srv/mythtv/a/recordings
> /srv/mythtv/b/recordings
> /srv/mythtv/c/recordings
>
> Mapped to the following Storage Groups like this:
>
> Default: /srv/mythtv/a/recordings, /srv/mythtv/b/recordings
> Sports: /srv/mythtv/c/recordings, /srv/mythtv/a/recordings
>
> Will that be ok? I'm trying to come up with a scheme such that the small space I have on /srv/mythtv/c/recordings that I want to use when I record sports will be safe if I accidentally fill that drive up and some other sports show is going to record.

Yes. Directories can appear in any or all Storage Groups.

Note, also, that is the sports shows are really important to you, you
can simply disable auto-expiration for those recordings. Changing the
recording rule (under Storage Options) to disallow auto-expire will
ensure that no future recordings from that rule will be allowed to
expire (unless you manually change one or more to allow it). Changing
existing recordings simply requires selecting them (i.e. if they're all
in the Sports /recording/ group--as opposed to a Storage Group--go to
Watch Recordings and use MENU|Change View Filter|Sports, select Sports
in the left-hand column, then MENU|Add this Group to Playlist), then (if
using a playlist to change multiple, MENU|Playlist Options, otherwise
just MENU followed by) Storage Options|Disable Auto Expire.

Disabling auto-expire for "important shows" is not a problem. Disabling
auto-expire for everything is a big problem--or even "everything" on a
single file system. So just make sure you have some shows on a file
system that allow expiration--enough to give a sufficient buffer for you
to notice that you're out of space and move things around or add more
space--with Deleted recordings (that could be expired) or auto-expirable
recordings.

Also, you may want to consider doing things a bit differently. Since
(at least from MythTV's perspective) physical location is irrelevant for
recordings, rather than trying to group all of your Sports recordings
into a specific set of directories, you may want to "migrate" some of
the sports recordings to a not-used-for-writing Storage Group once
they've been recorded to (any) Storage Group directory. The idea is to
create a Storage Group, such as "Archive" or "Protected" or "Read Only"
or whatever that has directories that do not exist in any other Storage
Group, and never specify the "Archive" Storage Group in any recording
rules. The end result is that MythTV would never actually write to
those directories (and, therefore, would never expire anything from
those directories), but would still find shows there for playback. So,
perhaps you just want to put /srv/mythtv/c/recordings into an Archive
Storage Group and "manually" move recordings there (manually meaning at
the command line using mv or whatever, or you could even use a User Job
to do so, and enable that User Job on your Sports recording rules, so
it's done for you when a recording completes).

See http://www.gossamer-threads.com/lists/mythtv/users/535888#535888 for
details.

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


mtdean at thirdcontact

Jan 14, 2013, 7:47 AM

Post #20 of 24 (1761 views)
Permalink
Re: Storage group question [In reply to]

On 01/14/2013 10:34 AM, Joseph Fry wrote:
>>> OK, that's what I thought would happen. A related question: Can the same
>>> directory be mapped into multiple Storage groups? For example, if I have 3
>>> directories for recordings like this:
>>>
>>> /srv/mythtv/a/recordings
>>> /srv/mythtv/b/recordings
>>> /srv/mythtv/c/recordings
>>>
>>> Mapped to the following Storage Groups like this:
>>>
>>> Default: /srv/mythtv/a/recordings, /srv/mythtv/b/recordings
>>> Sports: /srv/mythtv/c/recordings, /srv/mythtv/a/recordings
>>>
>>> Will that be ok? I'm trying to come up with a scheme such that the small
>>> space I have on /srv/mythtv/c/recordings that I want to use when I record
>>> sports will be safe if I accidentally fill that drive up and some other
>>> sports show is going to record.
>> Yes, the same path can be entered in multiple storage group definitions,
>> though I see little reason to assign the same paths to two storage groups,
>> at that point you could get away with just one. If your goal is a bit
>> more complex, you will want to keep in mind that mythtv has multiple
>> methods for balancing the load/storage of recordings within the storage
>> groups, you will want to select the one that makes the most sense to your
>> goals.
>>
> Oh, and if two storage groups contain the same path... I'm not exactly sure
> if mythtv will properly report the storage group for the individual
> recordings. For example if both the 'default' and 'sports' storage groups
> share a particular folder, you may find that the recordings to the 'sports'
> storage group will report that they are in the 'default' storage group. I
> know that mythtv will allow recordings to be moved around the file system,
> thus between storage groups, so I suspect that it will detect all
> recordings in a particular folder as being part of just one storage group;
> not both.

It actually stores the Storage Group with the recording metadata, but
never stores the physical location. Therefore, MythTV would always
report the correct Storage Group, even if there's overlap of directories
among Storage Groups. That said, you're probably right that the Sports
Storage Group (at least as described/envisioned) probably isn't
necessary, and my other reply gave Paul a couple other, probably better,
options for achieving what it looks like he wants.

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


joe at thefrys

Jan 14, 2013, 7:51 AM

Post #21 of 24 (1764 views)
Permalink
Re: Storage group question [In reply to]

> Oh, and if two storage groups contain the same path... I'm not exactly sure
>> if mythtv will properly report the storage group for the individual
>> recordings. For example if both the 'default' and 'sports' storage groups
>> share a particular folder, you may find that the recordings to the
>> 'sports'
>> storage group will report that they are in the 'default' storage group. I
>> know that mythtv will allow recordings to be moved around the file system,
>> thus between storage groups, so I suspect that it will detect all
>> recordings in a particular folder as being part of just one storage group;
>> not both.
>>
>
> It actually stores the Storage Group with the recording metadata, but
> never stores the physical location. Therefore, MythTV would always report
> the correct Storage Group, even if there's overlap of directories among
> Storage Groups. That said, you're probably right that the Sports Storage
> Group (at least as described/envisioned) probably isn't necessary, and my
> other reply gave Paul a couple other, probably better, options for
> achieving what it looks like he wants.
>
> Thanks for the clearification Mike... I suspected that it did store the
storage group in the metadata... but then I recalled that mythtv will let
you move a recording from one storage group to another (at least at the
file system level). Does it preserve the storage group even if the current
folder containing the recording isn't part of that storage group?


mtdean at thirdcontact

Jan 14, 2013, 8:18 AM

Post #22 of 24 (1764 views)
Permalink
Re: Storage group question [In reply to]

On 01/14/2013 10:51 AM, Joseph Fry wrote:
>>> Oh, and if two storage groups contain the same path... I'm not exactly sure
>>> if mythtv will properly report the storage group for the individual
>>> recordings. For example if both the 'default' and 'sports' storage groups
>>> share a particular folder, you may find that the recordings to the
>>> 'sports'
>>> storage group will report that they are in the 'default' storage group. I
>>> know that mythtv will allow recordings to be moved around the file system,
>>> thus between storage groups, so I suspect that it will detect all
>>> recordings in a particular folder as being part of just one storage group;
>>> not both.
>> It actually stores the Storage Group with the recording metadata, but
>> never stores the physical location. Therefore, MythTV would always report
>> the correct Storage Group, even if there's overlap of directories among
>> Storage Groups. That said, you're probably right that the Sports Storage
>> Group (at least as described/envisioned) probably isn't necessary, and my
>> other reply gave Paul a couple other, probably better, options for
>> achieving what it looks like he wants.
> Thanks for the clearification Mike... I suspected that it did store the
> storage group in the metadata... but then I recalled that mythtv will let
> you move a recording from one storage group to another (at least at the
> file system level). Does it preserve the storage group even if the current
> folder containing the recording isn't part of that storage group?

Yes, so if you move it from a directory in Default to a directory that's
only in, say, Archive, it will still show as being "in" the Default
Storage Group--though it's finding it in another directory.

Similarly, if your Default Storage Group contains the directory
/srv/mythtv/tv/c/recordings, today, and MythTV records a new recording
to that directory, and tomorrow you edit the directory list for Default
to no longer contain the /srv/mythtv/tv/c/recordings directory, the
recordings is still "in" the Default Storage Group, even though it's in
a directory that's no longer in that Storage Group.

Storage Groups are simply used a) as a way to command MythTV where to
write a recording and b) as a hint about where to find a recording once
it's recorded--to order our directory search for the recording file.
But, since changing the hint doesn't have any appreciable performance
benefit, there's no reason to update it when you move the recording
file. In the future, though, we'll have a better
(specific-to-the-directory-level) hint for where to find the recording
file, and that will be updated (automatically) when the recording
moves. At that point, the Storage Group will really only mean anything
to the recording rule, and not the recording itself.

So, really, Storage Group has little meaning once a recording is
recorded, which is why the vast majority of users probably only ever
need a Default Storage Group (for writing TV recordings) and, possibly,
an Archive Storage Group (for storing recordings on a "safe" file system
that won't ever experience auto-expiration)--in addition, of course, to
the "special" Storage Groups used by, for example, Video Library or DB
Backups or whatever.

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


joe at thefrys

Jan 14, 2013, 8:39 AM

Post #23 of 24 (1753 views)
Permalink
Re: Storage group question [In reply to]

> Thanks for the clearification Mike... I suspected that it did store the
>> storage group in the metadata... but then I recalled that mythtv will let
>> you move a recording from one storage group to another (at least at the
>> file system level). Does it preserve the storage group even if the
>> current
>> folder containing the recording isn't part of that storage group?
>>
>
> Yes, so if you move it from a directory in Default to a directory that's
> only in, say, Archive, it will still show as being "in" the Default Storage
> Group--though it's finding it in another directory.
>
> Similarly, if your Default Storage Group contains the directory
> /srv/mythtv/tv/c/recordings, today, and MythTV records a new recording to
> that directory, and tomorrow you edit the directory list for Default to no
> longer contain the /srv/mythtv/tv/c/recordings directory, the recordings is
> still "in" the Default Storage Group, even though it's in a directory
> that's no longer in that Storage Group.
>
> Storage Groups are simply used a) as a way to command MythTV where to
> write a recording and b) as a hint about where to find a recording once
> it's recorded--to order our directory search for the recording file. But,
> since changing the hint doesn't have any appreciable performance benefit,
> there's no reason to update it when you move the recording file. In the
> future, though, we'll have a better (specific-to-the-directory-**level)
> hint for where to find the recording file, and that will be updated
> (automatically) when the recording moves. At that point, the Storage Group
> will really only mean anything to the recording rule, and not the recording
> itself.
>
> So, really, Storage Group has little meaning once a recording is recorded,
> which is why the vast majority of users probably only ever need a Default
> Storage Group (for writing TV recordings) and, possibly, an Archive Storage
> Group (for storing recordings on a "safe" file system that won't ever
> experience auto-expiration)--in addition, of course, to the "special"
> Storage Groups used by, for example, Video Library or DB Backups or
> whatever.
>
> Thanks again! You would think that after over 10 years of using Myth I
would know all of this stuff... but I rarely experiment with my mythtv
setup once I have it working the way I like.


bigboi at wackywombats

Jan 14, 2013, 8:12 PM

Post #24 of 24 (1743 views)
Permalink
Re: Storage group question [In reply to]

On Jan 14, 2013, at 8:39 AM, Joseph Fry wrote:

>
> Thanks for the clearification Mike... I suspected that it did store the
> storage group in the metadata... but then I recalled that mythtv will let
> you move a recording from one storage group to another (at least at the
> file system level). Does it preserve the storage group even if the current
> folder containing the recording isn't part of that storage group?
>
> Yes, so if you move it from a directory in Default to a directory that's only in, say, Archive, it will still show as being "in" the Default Storage Group--though it's finding it in another directory.
>
> Similarly, if your Default Storage Group contains the directory /srv/mythtv/tv/c/recordings, today, and MythTV records a new recording to that directory, and tomorrow you edit the directory list for Default to no longer contain the /srv/mythtv/tv/c/recordings directory, the recordings is still "in" the Default Storage Group, even though it's in a directory that's no longer in that Storage Group.
>
> Storage Groups are simply used a) as a way to command MythTV where to write a recording and b) as a hint about where to find a recording once it's recorded--to order our directory search for the recording file. But, since changing the hint doesn't have any appreciable performance benefit, there's no reason to update it when you move the recording file. In the future, though, we'll have a better (specific-to-the-directory-level) hint for where to find the recording file, and that will be updated (automatically) when the recording moves. At that point, the Storage Group will really only mean anything to the recording rule, and not the recording itself.
>
> So, really, Storage Group has little meaning once a recording is recorded, which is why the vast majority of users probably only ever need a Default Storage Group (for writing TV recordings) and, possibly, an Archive Storage Group (for storing recordings on a "safe" file system that won't ever experience auto-expiration)--in addition, of course, to the "special" Storage Groups used by, for example, Video Library or DB Backups or whatever.
>
> Thanks again! You would think that after over 10 years of using Myth I would know all of this stuff... but I rarely experiment with my mythtv setup once I have it working the way I like.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Thanks for all the great info! I think I'll explore the "archiving" method that Mike mentioned.

Paul

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.