[mythtv-users] database recovery, no backup [solved except FE segfaults]

[Michael T. Dean]

On 08/16/2012 03:08 PM, Ross Boylan wrote:
> I think I have solved the original problem by (simplifying from some false
> starts), although now I'm getting segfaults on the 0.25 front end:
>
> Removed 0.25 myth, leaving database.
> Install myth 0.24.2 including the mythvideo package.
> Edit the schema version in the DB to be 1264 (it was 1266) (myth 0.24.2
> backend refuses to run otherwise).
> Start backend.
> Start frontend to invoke mythvideo database upgrade code.  Permit the
> upgrade to run.
> At this  point I have a non-crazy 0.24.2 database.
>
> Remove myth 0.24.2
> Install 0.25.
> Database upgrades.
> Backend will run.
>
> All is not completely well: the frontend segfaults before opening any
> windows.  I suspect there is a version mismatch with some of the libraries
> like Qt.  I have not kept the VM current since these problems developed a
> couple months ago (on the "if you're in a ditch, stop digging" principle).
>
> I also though I had seen some posts about problems caused by upgrading
> mysql from 5.1 to 5.5, which is what Debian wants to do.  The depencies do
> not let me upgrade qt without messing with mysql and/or myth (in the case
> of myth, that is "messing" in the sense of "removing").

All MySQL 5.5 issues should now be fixed in current MythTV.  I don't 
remember when we fixed them, but I know current 0.25-fixes works fine 
with MySQL 5.5.  (I /think/ 0.24-fixes should, too, meaning even a 
"broken" 0.25, such as the 0.25 release tarball, should work.)

> Oddly, if the frontend starts on a different account (root) it is able to
> popup the window asking for the database connection parameters (somewhat
> inconsistent with my theory about Qt version problems, assuming the window
> uses Qt).  After I enter those, the front-end segfaults.

The usual culprit for segfaults on startup after a version upgrade is 
having old versions of the MythTV libraries--and often, specifically, 
plugins--still on the system.  For example, if you have the MythVideo 
plugin file in /usr/lib/mythtv/plugins/ , it will almost definitely 
cause mythfrontend to segfault on startup.  Since there is no MythVideo 
in 0.25 (it was rolled into core), the plugin wouldn't be replaced by 
0.25 packages, and it seems sometimes it gets left in place.  The same 
goes for other outdated plugins, such as MythFlix or MythMovies or ...

In the case of corrupted MythTV schema and/or data, a partial database 
restore is often the best approach.  While it sounds like you may have 
other non-database problems (usually database issues won't result in 
segfaults), if you don't trust the provenance of your database/schema, 
you may want to consider creating a full backup of the 0.25 database, 
then doing 
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup 
.  Note, though, that it will require completely re-configuring 
everything after the partial restore.

> Further comments below.
> On Thu, Aug 16, 2012 at 9:34 AM, Michael T. Dean wrote:
>> I'll try to get a chance, soon, to look into the DB upgrade process for
>> users without MythVideo schema, but last I tested, it worked fine.  I'm
>> thinking if there was a problem, it was external to MythTV (i.e. something
>> killed and restarted mythbackend during the upgrade because it wasn't
>> responding or whatever...), but I will run a test, again, of a 0.24-0.25
>> upgrade of a DB schema without MythVideo schema.
> Thanks for your help.  I'm not sure any checking is warranted; the only
> explanation I can see of how things got this way required two odd things:
> first, the file system filled in the middle of an install, leaving the
> mythvideo tables in a very old state (since the code creates the tables by
> making a very old version and then upgrading it).  Second, after I made
> space I did not reinstall the mythvideo package (partly to save space), and
> so it never had a chance to complete updating the tables.
>
> If anyone has ideas about the segfault, or information on mysql 5.5
> compatibility,  that would be great.

Ah, yeah, if the file system filled up during the upgrade, that could 
definitely cause problems with the upgrade and leave the schema in a bad 
state.  Thanks for the follow-up.

Mike