[mythtv-users] Merging recordings from 2 backends

[Stephen Worthington]

On Wed, 8 Nov 2023 16:09:27 +0000, you wrote:

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

See my previous email on this thread about recordedid.