[mythtvnz] Mythbuntu 16.04 user experiences

[Stephen Worthington]

On Fri, 22 Jul 2016 08:21:02 +1200, you wrote:

>
>> If you still have a backup database with all the old recordings in it,
>> it is possible to get that data exported to the new system.  What you
>> have to do is install a virtual machine somewhere that is running the
>> same MythTV version as the old backup database.  Then you restore the
>> old database on that virtual machine, and upgrade the version of
>> MythTV to match the version on your real MythTV system.  Then you
>> install mythexport and use its On The Go web page to mark all the old
>> recordings in the database that you still have the files for to be
>> exported.  When it starts an export job, mythexport first stores a
>> .sql file to the export directory that contains all the data for the
>> recordings being exported.  Then it copies all the recording files to
>> that directory.  But I believe that if the recording files do not
>> exist (as they will not on the virtual machine), it will still create
>> the .sql file correctly.  So once it has done that, copy the .sql file
>> to the real MythTV system, and install the mythimport package there,
>> and then run mythimport on it.  All the data in the .sql file will be
>> imported into your database, and will then automatically match up with
>> the old recording files.
>>
>> If your old database does not quite match all the old recording files
>> you have, you can still do this process, and then manually deal with
>> the mismatched files.  There will be some files still without matching
>> database entries - find_orphans.py will tell you what the files are.
>> Those files will need to be moved to a videos directory.  Then you
>> have to manually play each file, and rename it to whatever programme
>> it contains.  For database entries that have no matching file,
>> find_orphans.py will automatically delete the database entries for you
>> if you tell it to.
>>
>> When doing such a large mythimport run, it is possible to have a
>> problem with the import process, so it can stop in the middle with an
>> error such as one recording that is in the old database is somehow
>> matching one already in the new database.  If that happens, you can go
>> back to mythexport and not mark that recording to be exported and try
>> again.  But for that to work, you need all the recordings in the new
>> database that have already been imported by mythimport to be removed.
>> The only safe way I know of to do that is to backup the new database
>> before starting the mythimport run, and doing the mythimport run at a
>> time when there will be no recordings on the box for long enough for
>> mythimport to complete successfully, or for it to fail and then for
>> you to restore the backup database before the next recording.
>>
>> Having backed up and restored databases many times, I can tell you
>> that if you follow the instructions, that process is very reliable so
>> there is no worry about having to do it should there be a problem with
>> importing the old database.  I have also used mythexport and
>> mythimport extensively, but only so far on MythTV up to 0.27 - I have
>> not tried it on 0.28 yet.
>>
>I have a quick question: are database backups from 0.27 compatible with  
>0.28?

That depends on what you mean by compatible.  There are quite
significant changes in the database schema between 0.27 and 0.28, such
as the addition of a recordedid field as the primary index for the
recorded table.  So the individual tables and rows from tables where
there are changes like that are incompatible.  Hence the output of
mythexport from 0.27 will not work with mythimport in 0.28.  But if
you do a full restore of a 0.27 database into a 0.28 system, that will
be detected when mythtv-setup or mythbackend is run, and the 0.27
database will be automatically upgraded to a 0.28 one.