[mythtv-users] Upgrading from pre-0.22 MythTV versions
raymond at wagnerrp.com
Fri Mar 30 04:30:56 UTC 2012
On 3/29/2012 23:58, f-myth-users at media.mit.edu wrote:
> > Date: Thu, 29 Mar 2012 23:31:19 -0400
> > From: Raymond Wagner<raymond at wagnerrp.com>
> > If the user installs a newer version of MythTV anywhere on the network,
> > and detects the wrong instance of MythTV over UPNP, they could tell
> > mythtv-setup to upgrade the wrong database.
> Is the detection automatic, or would I be prompted? Alternately, if I
> firewalled ports 1900 and 2869 on the old backend (or the new machine :),
> I assume this would inhibit this behavior without breaking anything else?
> (I -hope- this is moot---UPNP went into myth in... 0.22? I can't remember.
> I think my backend is too old to respond, but I don't know for sure.
> netstat -l shows nothing listening on either of those ports on my master,)
UPnP detection operates on UDP 188.8.131.52:1900. Every UPnP device
or software listens on that address for queries or announces. Each
query or announce carries in the datagram an independent address and
port that it will be listening on for a response. For MythTV, this is
the HTTP server at port 6544. IIRC, there was a dialog that would pop
up detailing the discovered backends, allowing you to choose between
them, but it has been a long time since I've used it.
This UPnP autodetection can be stopped by running `mythbackend` with the
--noupnp flag, or by having your backend listen on 127.0.0.1, or by
leaving the PIN empty. Alternatively, setting the PIN to anything other
than 0000 will require you to supply the proper pin back before the
backend will give up the access credentials. Should the remote machine
retrieve those credentials from the backend successfully, the database
must still be configured to accept those credentials from that host,
however with many users simply using a blanket subnet GRANT, that is not
Also note that mythtv-setup still requires the user to manually
authorize the update. Only the master backend running detached from a
terminal will update anything without asking first. On the other hand,
if users didn't have the propensity to click anything and everything
without reading, viruses wouldn't be the problem they are today. In the
interest of full disclosure, even I managed to do just that several
months back, upgrading my production install from `mythtv-setup` on a
test system I was configuring with a later version of 0.25pre. I'm
configuring a new database, of course I want to update it to the current
> > In either case, MythTV will
> > find somewhere to make a database backup, allowing the mistake to be
> > reverted.
> Who makes the backup? The new master or the old master? My old
> master predates these automatic backups (I have alternate tools).
All updates are run by the application that thinks the database should
be updated. Nothing gets routed through any other system besides the
database sever itself.
> Is the code that updates the schema smart enough to bail out without
> doing anything if the backup fails, such as due to a disk-full? I can
> think of more than one filesystems on my old master where a bulky ~1GB
> backup could conceivably fail in some circumstances.
There are a number of different paths the backup script will attempt,
including any defined storage directories, the users home directory, and
/tmp, before it eventually gives up and proceeds with the update without
a backup. By default, backups are gzipped in flight on their way to the
filesystem, so you're looking at a pretty massive database before your
dump manages to hit 1GB compressed.
More information about the mythtv-users