[mythtv-users] Merging Multiple Myth Installations

[Stephen Worthington]

On Mon, 30 Dec 2019 21:40:17 -0800, you wrote:

>I have multiple MythTV server installations, mostly not the current
>version.  They all have recorded shows.  I would like to combine them all
>into my current server, although there are some more modest goals that
>would be useful.  I'm looking for advice on how to proceed.  I am
>comfortable programming, including using SQL.
>
>I can run the other installations in real or virtual machines, or I could
>access the files directly.
>
>It's mostly recordings of TV shows I want to combine.
>
>There is quite a bit of information about this in the mailing list and the
>wiki, but I haven't seen anyone offering a program that does this.
>
>The intermediate goal would be to import the information on what shows I've
>recorded into my current installation, so that I don't record stuff I
>already recorded.
>
>Among the advice:
>1) First convert all databases into the current format.
>2) Never modify the database with SQL directly.  Though I'm happy to use
>python, with or without the services API, to delete a recording, it seems
>unlikely I'll avoid working in SQL.
>
>As to the main conversion, there have been a range of responses:
>3) It's not possible.
>4) Export and reimport the recorded (and maybe oldrecorded? oldprogram?)
>tables.  The references to recording rules, channel ids, and other stuff
>will be messed up, but the basic information should be there. (
>https://lists.gt.net/mythtv/users/442688)  If I copy the actual recordings
>to the current server, I should be able to watch them.  My guess is that
>pulling this off might require fiddling with the ids to avoid collisions.
>Also, don't copy stuff marked as future.
>5) Use some kind of myth or mysql database tool to dump the database, make
>"adjustments" and import it.  The non-existence of a script that does this
>suggests this is difficult.
>
>4) seems attractive.  I am not interested in migrating things like the
>channel and tuner setups or (probably) recording rules from old
>installations, except insofar as it allows me to make sense of the info
>I've migrated, e.g., what channel a recording is from.  I am somewhat
>unclear on the roles of recorded, oldrecorded, program, and oldprogram* in
>the system, and I've been somewhat puzzled by the fact that information in
>fields  that are defined for these tables is sometimes missing (e.g.,
>oldrecorded's season and episode are always 0, though recorded and  program
>have the information).
>
>I guess I can't just blow off chanid, recordid and programid since the
>table definition requires them to be non-NULL.  I'm not sure if it requires
>them to be valid foreign keys; https://www.mythtv.org/wiki/Development_guide
>says they are, but "show create table" does not show any formal foreign key
>constraints.  If such a constraint is in effect and the existing value is
>out of range, it will cause an error.  Otherwise it will just be a random
>bogus reference.   At any rate, recordedid would need to respect the
>primary key constraint.
>
>Does the information of which recording rule is associated with a
>particular recording (the recordid field) matter, or is it just
>informational?
>
>A perhaps simpler version of 4 is the suggestion to use MythArchive to move
>the recordings (see thread referenced earlier).
>
>It is likely I have some recording of the same show/episode made on
>different systems.  It is very unlikely the recordings will have been made
>at the same time.
>
>Thanks for any advice.
>Ross
>
>*Here's what I gather from the descriptions (
>https://www.mythtv.org/wiki/Category:DB_Table) of  recorded, program and
>the old* versions: program holds listings of the last couple of weeks and
>upcoming programs in the sense of a particular broadcast at a particular
>time on a particular channel, so they are from the listings provider.
>recorded has recordings actually made (or, maybe, attempted, or not done
>because they were duplicates--those are definitely in oldrecorded) and
>still available for viewing.  oldrecorded has everything in recordings +
>recordings that were deleted + future recordings.  oldprogram has only the
>title and time, and probably exists only to help myth decide if an upcoming
>program is new.  Since it records only the title, not the subtitle, episode
>info, or original airdate, I'm not sure how it has enough info to do even
>that.

I can help with moving recordings from one MythTV setup to a different
one.  I have a tool I wrote for that.  It is part of my "mythsgu"
Python program.  I have helped someone else do a bulk copy as you are
wanting to do and it worked well.  It works the same way as
mythexport/mythimport work (and uses mythimport at the receiving end),
but does bulk copies.  It is able to do the copying while both MythTV
systems are working as it checks for recordings (or playback) in
progress and pauses the copying when it sees either system is busy.
You do need to have file access (eg SAMBA or NFS) to the receiving PC
from the transmitting PC.

I have only thought about the oldrecorded table in passing - in
theory, it would be possible to transfer the data from that to a
different system, as long as the channels have the same callsigns in
both.  But I have never had the need to do that, so I have not written
any code.  It does not look to be too difficult a job, but you would
have to work out what the oldrecorded.findid field refers to and
transfer that as well.  The code for mythimport shows how to adjust
things like chanid and recordid which are unique on one database, but
would need to be changed to match the database they are being merged
into.

The publicly available versions of mythsgu and mythimport are
available on my web server:

http://www.jsw.gen.nz/mythtv/mythsgu
http://www.jsw.gen.nz/mythtv/mythimport/mythimport

In mythsgu, look at the "exportdir" and "copydir" commands.  Let me
know if you want to try using it - I think I should be able to dig out
the instructions I emailed the other person who used it.