[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