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

Mike Perkins mikep at randomtraveller.org.uk
Thu Dec 23 09:44:26 UTC 2021


On 22/12/2021 23:25, James 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)
> 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
> 
One reason would be to clean up the recording. Most recordings these days are of transport streams 
and will contain unwanted segments, be they adverts, trailers or just the station ident. In modern 
digital recording, every time one of those happens (at least here in the UK) there can be a format 
switch, ie from interleaved to progressive or even from 30fps to 25fps, etc.

It therefore makes sense to edit the original, extract using a cut list and then run it through 
something like Handbrake to produce a consistent - and often smaller - output file, possibly in a 
better format for subsequent playing. That is what most of the scripts like mythvidexport are doing.

-- 

Mike Perkins



More information about the mythtv-users mailing list