[mythtv-users] sanity check or repairing DB for 0.22 upgrade.

Michael T. Dean mtdean at thirdcontact.com
Thu Nov 19 01:20:56 UTC 2009

On 11/18/2009 08:09 PM, Alan Anderson wrote:
> Sanity check please.
> I have one master backend  mythbackend version: 0.21.20080304-1 and three 
> front ends.   I have had the same data base for 5 or more years.  Typically 
> when I upgrade I backup /var/lib/mysql upgrade the version  of fedora and 
> restore /var/lib/mysql.  So far it has always worked.  I have backups of 
> mythconverg but never needed them.  I also run the script 
> /usr/share/doc/mythtv-docs-0.21/contrib/optimize_mythdb.pl weekly.
> When I tried to install V0.22 I ran into the following scheme update issue.
> Query was:
> Driver error was [2/1283]:
> QMYSQL3: Unable to execute statement
> Database error was:
> Column 'filename' cannot be part of FULLTEXT index
> Every time I start a front end the error occurs.
> From my understanding this is issue where some UTF characters got into the 
> data base when everything should be latin1.   I need to do a partial restore 
> to fix this.  I need to fix the data base before I can upgrade to V0.22.

That's something very different.  I'd bet you're running with MySQL 
strict mode enabled (which is the default for MySQL on Windows)--which 
will break Myth.


(and I'm 99% positive that even TRADITIONAL mode will break myth).

If not, the problem is just the way you restored with binary data 
files.  You should /always/ use a SQL-based mythconverg backup when 
upgrading the MySQL server***.

Also note that dropping a 0.21-fixes database data files on top of a 
0.22-fixes database schema's database files will break Myth.  You need 
to ensure you DROP the 0.22-fixes database (or otherwise remove it 


***Yeah, I said "mythconverg backup," thereby implicitly excluding 
backups performed by MySQL database admins on work database systems.  
Basically, you have to know what you're doing /and/ what MySQL changes 
occured to reliably do binary-file restores.  There's no reason any 
MythTV user should /ever/ be expected to do this, so just use SQL-based 

More information about the mythtv-users mailing list