[mythtv-users] Theme problems upgrading to 0.22

Michael T. Dean mtdean at thirdcontact.com
Wed Jan 6 02:01:40 UTC 2010


On 01/05/2010 05:57 AM, Neil Bird wrote:
> Around about 05/01/10 01:29, Michael T. Dean typed ...
>>> ... the odd default_authority one which some people have seen).
>> It's not odd...  It's the "You restored 0.21-fixes schema mythconverg
>> database backup on top of a 0.22 schema mythconverg database."  In the
>> process, MySQL corrupts all your data (I hope when you reverted, you
>> went to the pre-upgrade backup...).
>
>   It was a *little* odd, but I didn't investigate fully;  the issue I
> had was caused by reverting to the original d/b by using the automated
> backup made by mythtvsetup.
>
>   A quick look at the file I used showed that it did have the extra
> default_authority schema info., which shouldn't have been there in the
> 0.21 data, so it was as if it backed up not what I started with, but
> something halfway through the backup.
>
>   A full wipe of the mythconverg tables and a restore from my manual
> backup got me trying again.
>
>   That said, I didn't double check that I really was using the first
> automated backup:  I ended up with several, some from mythtvsetup and
> some from mythfrontend as it tried to deal with the music/video d/b
> problems.  I may well have picked one from in the middle as opposed to
> the chronologically first one.
>
>   <checks>  Nope, the automated backups all have multiple
> default_authority fields in tables, where my 0.21 d/b only has one, so
> I don't know what the deal is with them.  I'll need to remember to
> always use my own backup I guess.

That can happen if something kills mythbackend when it's upgrading the
database and then something restarts mythbackend (i.e. monit et. al.
will do this because the backend won't respond to polling/requests until
it's finished upgrading the schema, so the watchdogs get scared and
preemptively do bad things).  I've heard (though not investigated) that
some distro(s) are using their own backup script that overwrites the
previous backup (and keeps only one), so if that were the case, in this
situation of killing and restarting mythbackend, you'd end up with
backups from midway through the upgrade after it deletes the backup made
before the original upgrade.

Even with the mythconverg_backup.pl script--which keeps only the last 5
backups--you'd get the same result if the watchdog killed mythbackend a
5th time.

>> By the way, the mythconverg_restore.pl script will prevent you from
>> restoring a backup onto a populated schema...
>
>   Yes, I will make sure I start using this.
>
>
>> So, long story short...  Shut down mythfrontend, restart, and enjoy the
>> theme you had selected.
>
>   Ah, OK, that makes sense.  Quitting was the one thing I wasn't trying.

Yeah.  Unfortunately this isn't intuitive, I could probably put a
message in the logs that says to change the theme to a valid theme and
restart, but didn't think of it when we were getting the last-minute fix
in place.

>> Solution to the problem:  get rid of all your 0.21-fixes garbage.
>
>   Yes, I'll make sure and move them all out of the way next time I
> give it a bash!
>
>
>
>   All of which only really leaves the font/config question:  why might
> Terra have been showing fonts at dodgy sizes?  And now I think about
> *that*, I do recall still seeing the font-size settings in the config.
> menus, and I *know* I've fiddled with those.  What are the default
> settings for those?


Those shouldn't matter.  The only one that still has an effect is the
"Fine tune font size (%)" setting (which defaults to 0%--i.e. use the
theme-specified sizes).

Note, though, that if you don't have the theme-specified font (and Terra
uses Arial, from the MS core web fonts package), X will give us a "close
match" that's almost never a close-enough match.

Mike


More information about the mythtv-users mailing list