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

James jam at tigger.ws
Wed Dec 22 23:25:29 UTC 2021

> 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)
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.

More information about the mythtv-users mailing list