[mythtv-users] Switching a MythTV laptop between independent and networked operation
R. G. Newbury
newbury at mandamus.org
Sat Jan 28 18:59:23 UTC 2012
On 01/27/2012 07:46 AM, Simon Hobson wrote:
> John Pilkington wrote:
>
>> I'd also like to be able to switch transmitter easily, for independent
>> use of the laptop in other places. That might follow naturally from
>> such a script, but at present I find that importing an earlier scan in
>> the mythtvsetup channel editor doesn't carry the dvb transport settings
>> with it.
>
> I think for that you'd need to work out which tables hold the
> required data - tuners, transports, channels, etc, etc. Then you'd
> need to make a "master" copy of each setup, dump it somewhere, repeat
> for each location/transmitter. Then to switch transmitters, have a
> script that will empty the relevant tables and load the previously
> saved data.
>
> It will need a lot of care to get all the data you need, and not
> mangle anything that shouldn't change.
>
> An alternative, and I think vastly inferior, option may be to :
> At each location, delete all channels, then do a full scan to find
> the local transports and channels. Once you've been a location once,
> then you'd only need to "scan existing transports" which would save a
> little time tuning to channels it's never going to find anything on.
> After than run a "channel cleanup" script to set the channel numbers,
> xmltv id's, visibility etc.
>
> Why do I think it's inferior ?
> Well to start with, you'll be scanning a lot of transports that won't
> exist - say you have 4 locations, that's 4x5 muxes, so 20 muxes of
> which 15 won't be transmitted in your area. If you have HD, then 4x6,
> so 18 of 24 that won't be there.
> Also, in some locations you'll pick up local repeaters (possibly
> multiples) as well as a main transmitter. So you'll have to weed
> those out of the transports table. On the other hand, in some
> locations you may need these local repeaters - so you run the risk of
> leaving them in the transports table - only to appear elsewhere when
> you don't want them.
> All this means you'll spend more time to get a potentially inferior
> lineup - vs spending a little time up front and having nearly instant
> setup swaps.
>
> Of course, channel lineup changes by the broadcasters will be a pain
> - just as they are normally, but multiplied by the number of
> locations you use !
>
For networked use, the laptop has to look to the master backend as the
mysqld server. This is true whether it is a frontend or a slave backend.
Since you are referring to it as a slave, I presume you have something
like a USB tuner attached.
Note that myth uses the mysql.txt and config.xml files to FIND the mysql
server. So for any use as a slave or pure FE, it has to look for that
other box.
For BE/FE use, the FE looks at the local backend. On top of this, you
want to have the BE/FE situated in different locations and receiving
different physical channels.
I think this can be done, but there are large parts of the map marked in
bright red HERE BE DRAGONS.
I am not sure anyone has tried this, so the usual prescriptions apply:
make three backups of your mythconverg database first, and take two
aspirin with plenty of water (for the carpel tunnel aches) and two large
shots of your favourite medicinal spiritous liquor. With tonic water,
for the malaria..
For the mobile use, I think you need to use a separate MOBILE USER
different then the slave setup user. Then create a mythfrontend wrapper
script in /usr/local/sbin which is listed before the folders where
anything else resides, in your PATH. The wrapper will take /set a new
hostname (location-specific), and then (re)start mysqld, mythbackend and
then mythfrontend. The MOBILE USER home folder will contain mysql.txt
and config,xml files pointing to the laptop as the mysqld server.
The mythconverg database will happily contain and provide location
specific data, identified by the unique hostname, You will have to be
careful in running and setting up the tuner data at each site, and
tieing it to the data source. You will end up with multiple records
which except for the actual tuning data, will be similar but for the
hostname. For example, you will end up with one row for each hostname
for each 'value' in mythconverg.settings, (Just like having separate
databases for each location, as far as myth is concerned as mysql takes
care of parsing the data for each location.
Luckily, /etc/hosts is supposed to happily allow multiple aliases for
the same IP address, so the actual networking side of things should not
need to be touched: ie '192.168.100.2 laptop.domain.com
laptop,york,lincoln,london,newbury' should work fine and you set
hostname=lincoln etc. on restart.
So at each location, the FE thinks it is a different host, and uses the
(location specific) data for that location. all of which is contained in
the same mythconverg database on the laptop.
For the slave use, I think you need a completely different user, since
the mysql.txt and config.xml files have to point to the actual master
mysql server. It might be necessary to set a different hostname but I
don't think so. But /etc/hosts on the MBE should match that on the
laptop, so it should not matter which hostname the laptop is using. The
difference is in the username which forces use of the MBE as the mysqld
server.
In this case, the slave does not reference a local mythconverg database,
but the MBE instead. I suggest that you again write a wrapper script for
mythfrontend which kills any running mythbackend on the laptop, and
shuts down any mysqld server instance, before starting mythfrontend. Let
mythfrontend handle anything mysql related. Since this is a slave
backend, it may run its own mysqld server (don't know that for sure)...
Let mythfrontend deal with that.
Now off you go and see what happens. And if your map is black and white,
the red fire-breathing dragon is just to the left of the green rock.
Geoff
--
More information about the mythtv-users
mailing list