[mythtv-users] Upgrading from pre-0.22 MythTV versions

[Raymond Wagner]

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 239.255.255.250: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 
unlikely.

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 
schema!

>      >  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.