[mythtv-users] Tagging recordings (partial database restore)

[Michael T. Dean]

On 09/10/2009 12:05 AM, Panachoi wrote:
> From: "Michael T. Dean"
>> On 09/09/2009 09:41 AM, Gary D Walborn wrote:
>>     
>>> I suppose that this has been mentioned before, but MythTV should tag
>>> files with enough info to import the file into the system (and the
>>> database).  I'm not sure if the nuppelvideo format support tags.  I'm
>>> quite sure that all the mpeg formats do.  I suppose a separate file with
>>> tags would be better than nothing, but that should be an option.  I ran
>>> MythTV for a couple of years and recently upgraded the system, skipping
>>> several versions.  I backed up my database but have been unable to get
>>> hundreds of recordings in the new version.  If I try to import just the
>>> recording info (not the entire database), I get a message that columns
>>> are missing.
>>>       
>> That's because, as described at
>>
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
>> :
>>
>> Note, however, that it will only work if the backup schema version is
>> identical to the schema version used by the currently-installed
>> mythbackend.
>>
>> I added additional information and instructions for how to do a partial
>> restore when also changing versions.  (But it's probably too late for
>> you, now.)
> This is a bit scary; I've moved my recordings data between mythtv instances
> (I have a single NFS filestore for the recordings) several times before,
> without problems. I'm normally not *EVER* restoring the entire database,
> just the recordings info, by dumping the following tables into its own file
> with mysqldump:
>
> record recorded oldrecorded recordedprogram recordedrating recordedmarkup
> recordedseek
>
> And then restoring them on the new instance with mysql.
>   

Why not a full export?  Assuming your hostname remains the same, there's 
absolutely no reason to do a partial export.  And, if your hostname 
changes, using the restore script to change it means there's still no 
need for a partial export.

A partial export is basically a last-resort for when something is wrong 
with your database and you want to get only the not-recreatable data out 
and throw away everything else.

If you are doing a partial backup/partial restore, you should use the 
backup/restore scripts (as they're updated to fix issues/support changes 
to the schema).  The backup script always does a full backup and with 
the restore script, you /can/ choose to use the same full backup for a 
partial restore or you can use it for a full restore.

> In fact, I dump this to a file on a weekly basis, and export it to a safe
> place. I'm also doing this with my dtv_multiplex and channel tables (less
> useful, but has come in handy)
>   

Again, you /should/ do full database backups.  Try the backup script:

http://www.mythtv.org/wiki/Database_Backup_and_Restore

> I'm normally running a production and test instance master backends. I'm in
> the midst of migrating my "Old" production (svn 20028 with the original S2
> patches in ticket 5882) to the new production (svn 21731). A straight
> backup/restore was not possible ("hacks" to the DB to support the original
> S2 implementation). So I've already got a "new" database instance with some
> recordings in it on the new production backend, and just want to merge in
> the recordings from the old backend. Using the orphans script is definitely
> *NOT* an option!
>
> Are you suggesting this will not work any longer, or that I was lucky to
> have it work at all ?

Depending on the schema changes it may not.  I know nothing of the patch 
that was posted, but was never incorporated, that changed the schema to 
allow the use of DVB-S2 before it was supported in Myth.  So, it may or 
may not have broken your data.

Mike