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

[Panachoi]

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.

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)

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 ?


Message: 13
> Date: Wed, 09 Sep 2009 13:04:02 -0400
> From: "Michael T. Dean" <mtdean at thirdcontact.com>
> Subject: Re: [mythtv-users] [mythtv] Tagging recordings....
> To: mythtv-users at mythtv.org
> Message-ID: <4AA7E002.8080700 at thirdcontact.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> <Moving to the -users list>
>
> 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.)
>
> >   If I import the whole database, the new version does not
> > seem to be able to upgrade the database to the new version (I get
> > repeated upgrade messages even though I select "Upgrade" from the
> > dialog.  It MUST be easier to import pre-existing files into MythTV.
> > This is very frustrating.
>
> Please show me exact errors from the log file.  You should see 2 prompts
> asking if you want to upgrade.  The first before the backup, the 2nd
> after the backup (and allowing you to stop if the backup failed).
> Therefore, depending on how many "multiple prompts" you see, everything
> may be working fine.  (Note, also, that you'll get a prompt for
> upgrading the MythMusic DB schema version when you start
> mythfrontend--we haven't got prompts for other plugins, yet, though.)
>
> I recommend going back to your old-version database backup and doing a
> full restore.  Also, and *most importantly* the upgrade to current
> trunk's database schema version takes a *long* time.  (
> http://www.gossamer-threads.com/lists/mythtv/users/396252#396252 ).  Do
> not stop it mid upgrade or you will corrupt/break your data.
>
> Note, also, that there is no difference going between 0.21-fixes and
> trunk or going between 0.18 and trunk--the same path is followed, but in
> the former case, it's just been done in gradual steps.  Therefore, it's
> highly unlikely there are problems with the procedure used in the Myth
> code as it's been very well tested by a lot of users.
>
> Mike
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090910/a0ea2e00/attachment.htm>