[mythtv-users] Migrating recordings from <= 0.27 to 31

[Stephen Worthington]

On Thu, 23 Dec 2021 07:25:29 +0800, you wrote:

>> On 23 Dec 2021, at 2:09 am, Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:
>> 
>> On Wed, 22 Dec 2021 11:08:31 -0600, you wrote:
>> 
>>> I'm getting ready to replace a family member's MythTV backend with a new 
>>> PC. The new PC will have MythTV 31. The old PC has a > 7 year old MythTV 
>>> (0.27 or earlier) with a few dozen recordings. The recording schedule is 
>>> pretty simple so I'm OK with starting from scratch with a new 
>>> configuration were it not for the recordings.
>>> 
>>> Originally I'd thought I'd convert the recordings to videos on the old 
>>> backend then 'scp' them over to the new backend, but I'm not having any 
>>> luck with the mythvidexport2.py script I downloaded: a job gets added to 
>>> the queue but sits there and never runs. Also I see that the script has 
>>> to do some kind of encoding of the video file. This has me concerned 
>>> that it might get time-consuming to migrate a lot of recordings this way.
>>> 
>>> Now I see that it might be possible to restore the old backend's 
>>> database on the new backend system.
>>> 
>>> Questions:
>>> 
>>> 1. What is the correct way to submit a user job and force it to run as 
>>> soon as possible?
>> 
>> User jobs need to be enabled, and there are settings for how many user
>> jobs can be run at once - generally this should not be set any higher
>> than the number of CPU cores available.  The job queue is only checked
>> every so often (30 seconds?) and if there is a spare slot for a job,
>> the top job will be started.
>> 
>>> 2. Is it safe to use the mythconverg_restore.pl script to do a full 
>>> restore of a backup taken on a <= 0.27 backend to a 31 backend?
>> 
>> No.  It depends on just how old the database schema is.  I can not
>> remember where the cutoff point is, but v31 only has schema update
>> code back a certain number of versions.  If the database schema is
>> older than that, you have to do the upgrade in two steps.  First you
>> install an older MythTV version (say 0.27, but I am not sure of the
>> correct version) that has all the older schema update code.  You
>> restore the database on that version, run mythtv-setup to update the
>> schema, and then backup that database.  Then you can restore this
>> intermediate database to a v31 system and run mythtv-setup to get it
>> updated to the v31 schema.  The easy way to do this is to use a
>> virtual machine, and install Ubuntu 16.04 say (if that has the correct
>> intermediate MythTV version).  You can find out the last version that
>> has all the older schema update code by reading the release notes on
>> the mythtv.org website.  A number of people have done this sort of
>> upgrade now, and it is reasonably straightforward, if rather tedious.
>> 
>>> 3. Assuming I can do a full database restore, is there anything I have 
>>> to do with the recordings other than 'scp' them to a recordings storage 
>>> directory on the new backend?
>> 
>> No, there is nothing else that needs doing.  But scp is very slow
>> compared to using a SAMBA connection (the traffic is encrypted).  Even
>> better is to just take the old hard drive(s) from the old machine and
>> temporarily attach them to the new PC and copy from one drive to the
>> other.  Or just mount them permanently on the new PC and point storage
>> directories to them.
>
>Why is it considered not possible to just copy recordings and videos to videos directory?
>I do, and it works for me, the only issue is recordings get funny names like 1099_20200426133000.ts.
>(well meta data for videos is gone too)

Yes, you can just copy recordings to a videos directory.  You lose a
number of abilities based on the data stored in the database for
recordings.  Obviously, you lose the EPG data that tells you what the
recording is, but that can be overcome somewhat by using one of the
scripts that renames the files when copying them so that they have at
least the title and episode data in the name.  But you also lose
useful things like using the O key to see if there are going to be any
new recordings of a series, for example.

Moving recordings to videos has always seemed to me to be a wasteful
thing to do - one of the joys of using MythTV is just how good it is
at doing all sorts of little things with recordings.  Which you lose
by moving them to videos.

>I have a Gb network and scp transfers files at 100 (actually a strange number like 107) MB/s
>
>I'm not being a troll in any way and my only motivation is to learn, but the above advice sounds like . . . um . . . crap. (I am not talking about database words-of-wisdom)
>Even on a 100Mb network - enjoy lunch while it gets done.
>James

If you have fast enough PCs at each end, scp can be reasonably fast.
Or if you are using an ancient (and now unsafe and deprecated) cypher.
In this case, the old MythTV box sounds quite old and is unlikely to
be fast enough for fast ssh encryption.

Of course, if there are only a very few recording files to copy, then
just about any method will work.  But recording files tend to be
decently large, so it does not take too many of them to take a long
time to copy them.  And if the copying process will interfere with
doing recordings on one or other of the systems at the same time, you
only want the copying to happen when they are both idle, so you want
it done in the shortest possible time.  You have to remember that when
you are making recordings, the write rate to disk for each recording
is relatively small compared to the full speed of the disk.  When you
are copying files, the disk will be running at full speed for reading
or writing.  So having one recording running on the same disk at the
same time risks having it damaged.  Having more than one recording
running at the same time pretty much dooms the recordings - the disk's
heads will not get back to the recording file locations in time for
mythbackend to write the buffered data before it runs out of buffer
space.