[mythtv-users] Couple of questions on migration

[Michael T. Dean]

On 07/18/2017 02:44 PM, DryHeat122 . wrote:
> I am trying to migrate an old (12.04) Mythbuntu mythconverg to a new 
> (16.04) setup. I have two questions about this.
>
> First should I restore the database after installing the new mythbunto 
> but before running mythtv-setup, or should I run setup first?

You need to restore the database before running *any* MythTV 
application--including mythtv-setup and mythbackend.  Otherwise, they 
will populate the database schema, so you won't have the (required) 
empty database for the restore.

https://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore

If, for any reason, you have tables in your schema, you can always 
restore with

--drop_database --create_database

to get rid of (permanently delete--so make sure that's what you want to 
do) the existing database/schema/tables/data and create a new, empty 
database into which the restore will work.

https://www.mythtv.org/wiki/Database_Backup_and_Restore#Replacing_an_existing_database

> Second, though mysqlcheck found no problems with the old database, the 
> backup file appears to have some corrupted data in the recordedseek 
> table.  There are two insert statements, one with what look like valid 
> values, i.e., with the form
>
> (2025,'2016-08-01 14:00:00',126,5828752,9).
>
> But there is a second insert statement that is fine for hundreds of 
> values then starts including non alphanumeric characters like:
>
> (3008,'2017-04-#1h;0:00:0 'l9144:9
0876305648,9),(3200-'2017-04-11$2 
> 800:00',1 4ñ=7<4x0020;2 0¨9)
>
> I'm sure this is not right and that mysql will choke on them.  I'm 
> wondering what are the consequences of deleting these invalid values, 
> i.e. ending the insert statement at the last valid value.  I think but 
> am not sure that this table tracks commercial flagging so would I only 
> lose commercial flagging for the associated programs?
>

Chances are if there's a problem with them, MySQL will complain and 
either the restore will proceed and ignore the bad records or the 
restore will fail.  If it fails, you can then try editing the backup and 
then re-restore using the

--drop_database --create_database

arguments, as above.

Mike