[mythtv-users] Merging recordings from 2 backends
Paul Harrison
mythtv at mythqml.net
Wed Nov 8 11:14:32 UTC 2023
On 08/11/2023 10:17, Stephen Worthington wrote:
> On Wed, 8 Nov 2023 08:59:12 +0000, you wrote:
>
>> On 08/11/2023 03:17, Stephen Worthington wrote:
>>> On Tue, 7 Nov 2023 13:28:37 -0500, you wrote:
>>>
>>>> The mythsgu option seems to be the best for me. I'll essentially be moving
>>>> all the recordings from computer B and decommissioning it once I get back
>>>> to backend A. I'll be doing it in a few months, so I'll bookmark this
>>>> thread. Can't wait to really explore mythsgu.
>>> If you are fully decommissioning computer B, then you should consider
>>> just moving its recording drives into computer A and adding them to a
>>> storage group. Use mythsgu exportdir first in computer B, and then in
>>> computer A mythimport will find that the recordings are already in a
>>> storage group and will just import the .sql files and leave the
>>> recordings where they are.
>> I haven't tried or looked at these scripts, but in the past I did use
>> the mytharchive plugin ( Optical Disks > Archive Files >
>> Create Archive ).
>>
>> But Importing this to another system transferred the original
>> RecordedId, which is dangerous. The RecordedId value is created by
>> autoncrementation when a recording is set up, and is system-specific.
>> Just blindly creating a duplicate can corrupt the DB.
>>
>> One way of avoiding this is to overwrite the file of an unwanted
>> recording, regenerate its seektable and edit its title, but that won't
>> transfer other metadata.
>>
>> John P
> Mythimport assigns a new recordedid when it imports the SQL for a
> recording.
I'm probably stating the obvious but MythArchive is not Mythimport.
Many moon ago I used the native import from MythArchive to transfer the
odd recordings between systems and it worked well, it is what it was
intended to be used for. Unfortunately as is common changes to other
parts of MythTV broke that functionality. As John pointed out the
addition of RecordedId in the DB schema has not been taken into account.
It's a fairly trivial change to fix it it just need someone who cares
enough to do the work.
Paul H.
More information about the mythtv-users
mailing list