[mythtv-users] Backend quits functioning

William Powers wepprop at sbcglobal.net
Mon May 29 22:38:16 UTC 2006


Mark Knecht wrote:
>    Thanks, but it's not so easy.
>
>    It's a huge job to upgrade here. I've got a back-end machine with
> two tuners and then 5 separate frontend machines accessing it. Since
> the Myth devs decided that frontends and backends must match versions
> it's too many machines to deal with all at once. I have a wife and kid
> watching these things daily. It goes down and I'm in trouble! No
> thanks!
>
>    Possibly in July I'll get a break as they go off on vacation. Until
> then I'm stuck.
>
>    I'll hold out some hope that 0.19 fixes this crash problem.
First, please don't get the idea that 0.19 is a panacea for all 
problems.  I ran 0.18.1 for 8 months without a single hiccup but after 3 
months on several versions of 0.19 and subs, I'd go back to 0.18.1 in a 
heartbeat if I could.  Unfortunately I waited so long to decide I wanted 
to, that it was no longer easy to do so.

On the other hand, with a total of two backends and four frontends, I'm 
familiar with the problems of upgrading you mention and I've pretty much 
got it down to a science.  For me, the key to making upgrading easy is 
the ability to quickly go back to the previous (working) version if 
something goes wrong during the upgrade.  After trying several methods, 
it finally turned out to be easiest for me to install Myth from source.  
First, I use apt or yum or smart or source or whatever it takes to 
configure all the boxes so I can compile Myth on it.

Then I use ssh to log in to each box remotely and compile ('make') the 
new version but I don't do a 'make install'.  Once I have the new 
version compiled on all the boxes, I then find a free hour or so when no 
one is watching TV or recording anything when I can perform the 
upgrade.  7:00 am Sunday morning always seems to be available... :)

To perform the actual upgrade, first I save the database per the 
instructions in the docs.  Downgrading is easy with a copy of the 
previous database but it's darn near impossible without it.  Next I ssh 
to each box and stop all the backends.  Finally, I go back to the new 
version source directory each box and do the 'make install'.  Then I 
restart the backends, master first, and then the frontends.

If something goes wrong, I stop everything, delete any test recordings 
I've made since the upgrade, drop the database using the instructions in 
the docs, and restore the previous version of the database from the 
backup.  Then I go back to the source directory for the previous (older 
but working) version on each box and do 'make install' again (which 
overwrites the new version binaries with the older version binaries).  
Then I start the backends, then the frontends.  I can do the whole 
thing, installing a new version, testing it, and downgrading to the old 
version, in well under an hour.

The one drawback is that the longer you spend on the newer version, what 
with new recordings and new schedules, the more painful it is to go back 
to the older version.

If anyone is contemplating changing from an rpm-style install to a 
source install, uninstall the rpm version before installing the source 
compiled version:  It's likely they don't install to the same directory 
and you *don't* want to deal with having two versions installed at the 
same time.  If necessary, first install the same version you had 
installed with rpm's as step one, then do the upgrade to the newer 
version.  That will ensure the previous version binaries are easily 
available should you need to downgrade.  Of course, there's other ways 
to handle that step, such as keeping the old version rpm's handy, 
renaming the old version binaries in-place, etc.

Just my experiences.  YMMV.

Bill


More information about the mythtv-users mailing list