[mythtv-users] Merging recordings from 2 backends

[Mike Perkins]

On 08/11/2023 12:18, Stephen Worthington wrote:
> On Wed, 8 Nov 2023 11:12:41 +0000, you wrote:
> 
>> 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.
>>>
>> There is a potential conflict there, then. If, as described above, you have already moved the files
>> across they will be there with their original - and likely conflicting - programids. Is mythimport
>> smart enough to find the files with the old programids and change the ids to new ones? What happens
>> if there is a conflict and files with the same programid exist in two different storage directories?
> 
> Mythimport does not touch programid values.  They come from the EPG
> data and can be duplicated anyway if you record the same episode of a
> programme more than once.  Or if the EPG data is wrong.  Or if two
> different channels choose to use the same data to identify different
> programmes.
> 
> Long ago I accidentally used mythimport to import a programme that was
> already recorded locally, and it worked fine - there were two
> recordings in the listings, and they could both be played and deleted
> without problems.  So now I do that deliberately occasionally, for
> example when a recording was cut short by a problem on my MythTV box,
> but my mother's MythTV box has a good copy of it.  I just import the
> good copy and then can delete the bad one if the new one is better (it
> usually is).
>
Whoops! I did not mean programid, I meant *recordedid*. Slack editing. My comments above stand with 
that correction.

-- 

Mike Perkins