Mailing List Archive

On box B, you can export them to videos using mythvidexport.py on mythtv.org <http://mythtv.org/>.

Then move the videos to box A into your videos directory and rescan your videos.

I don’t know of any method to bring them in to the recordings directory. Too much database magic I suspect.

Regards

> On Nov 7, 2023, at 9:41?AM, Ian Evans <dheianevans@gmail.com> wrote:
>
> Just curious if this is possible...
>
> Let's say you have two mythboxes in different physical locations. Let's say a cottage or RV. At some point, you decide you'd like to have the recordings from box B on box A. Is it possible to import the recordings data into the database so that the recording info appears on box A?
>
> I realize that one could export the recordings as videos and just place them in the Video storage group, but if you want to import them into Recordings so you can easily edit them, is there a way to export/import their info from the database?
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

On Tue, Nov 7, 2023, 9:55?a.m. Jay Harbeston <jharbestonus@gmail.com> wrote:

> On box B, you can export them to videos using mythvidexport.py on
> mythtv.org.
>
> Then move the videos to box A into your videos directory and rescan your
> videos.
>
> I don’t know of any method to bring them in to the recordings directory.
> Too much database magic I suspect.
>
> Regards
>
> On Nov 7, 2023, at 9:41?AM, Ian Evans <dheianevans@gmail.com> wrote:
>
> Just curious if this is possible...
>
> Let's say you have two mythboxes in different physical locations. Let's
> say a cottage or RV. At some point, you decide you'd like to have the
> recordings from box B on box A. Is it possible to import the recordings
> data into the database so that the recording info appears on box A?
>
> I realize that one could export the recordings as videos and just place
> them in the Video storage group, but if you want to import them into
> Recordings so you can easily edit them, is there a way to export/import
> their info from the database?
>
>
Yeah, I already have used mythvidexport.py in the past. Was really hoping
there was a way to get keep them in Recordings for easy editing.

Thanks.

>
>

On Tue, 7 Nov 2023 09:41:06 -0500, you wrote:

>Just curious if this is possible...
>
>Let's say you have two mythboxes in different physical locations. Let's say
>a cottage or RV. At some point, you decide you'd like to have the
>recordings from box B on box A. Is it possible to import the recordings
>data into the database so that the recording info appears on box A?
>
>I realize that one could export the recordings as videos and just place
>them in the Video storage group, but if you want to import them into
>Recordings so you can easily edit them, is there a way to export/import
>their info from the database?

Yes, that is what mythexport/mythimport does. Mythexport has a web
page that allows you to select the recordings to be exported, and
where to store the exported files. Each recording file is accompanied
by a .sql file with all the metadata from the database. Then
mythimport will read the .sql file and add it the destination
database, and move the recording file into a storage group directory.
I use this to export recordings from my main MythTV box to drives I
mount on my laptop, so I can take recordings away on holiday with me.

Mythimport is easy to set up - just put its python file into
/usr/local/bin. Mythexport is rather more difficult now, as there are
no proper package files. I have not done it for ages, but if it still
works, you would download the mythexport package and do an "apt
install ./<package>.deb" command. Then you would need to download
some updated files and put them over the old files in the directories
they are installed in. Let me know if you would like to try this, and
I will get together the updated files and put them on my web server.

I have also written a "mythsgu" program that has a command "mythsgu
exportdir" which creates all the export .sql files for mythimport to
use for an entire directory of recording files. Then you can use
"mythsgu copydir" to copy that directory over the network to the
destination PC or just simply copy the entire directory to a portable
drive and attach that to the destination PC. Then you can run
mythimport on the directory.

http://www.jsw.gen.nz/mythtv/mythimport/mythimport
http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3.deb
http://www.jsw.gen.nz/mythtv/mythsgu
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 07/11/2023 15:33, Stephen Worthington wrote:
> On Tue, 7 Nov 2023 09:41:06 -0500, you wrote:
>
>> Just curious if this is possible...
>>
>> Let's say you have two mythboxes in different physical locations. Let's say
>> a cottage or RV. At some point, you decide you'd like to have the
>> recordings from box B on box A. Is it possible to import the recordings
>> data into the database so that the recording info appears on box A?
>>
>> I realize that one could export the recordings as videos and just place
>> them in the Video storage group, but if you want to import them into
>> Recordings so you can easily edit them, is there a way to export/import
>> their info from the database?
>
> Yes, that is what mythexport/mythimport does. Mythexport has a web
> page that allows you to select the recordings to be exported, and
> where to store the exported files. Each recording file is accompanied
> by a .sql file with all the metadata from the database. Then
> mythimport will read the .sql file and add it the destination
> database, and move the recording file into a storage group directory.
> I use this to export recordings from my main MythTV box to drives I
> mount on my laptop, so I can take recordings away on holiday with me.
>
> Mythimport is easy to set up - just put its python file into
> /usr/local/bin. Mythexport is rather more difficult now, as there are
> no proper package files. I have not done it for ages, but if it still
> works, you would download the mythexport package and do an "apt
> install ./<package>.deb" command. Then you would need to download
> some updated files and put them over the old files in the directories
> they are installed in. Let me know if you would like to try this, and
> I will get together the updated files and put them on my web server.
>
> I have also written a "mythsgu" program that has a command "mythsgu
> exportdir" which creates all the export .sql files for mythimport to
> use for an entire directory of recording files. Then you can use
> "mythsgu copydir" to copy that directory over the network to the
> destination PC or just simply copy the entire directory to a portable
> drive and attach that to the destination PC. Then you can run
> mythimport on the directory.
>
> http://www.jsw.gen.nz/mythtv/mythimport/mythimport
> http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3.deb
> http://www.jsw.gen.nz/mythtv/mythsgu
>
I would add that, since mythtv doesn't care which storage directory your recordings are in, it would
be possible to move them /out/ from among the countless other recordings and place them into a
separate directory before using mythsgu. Of course that new directory would have to be added as a
recording storage group, at least for the life of the export process.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, 7 Nov 2023 15:42:10 +0000, you wrote:

>On 07/11/2023 15:33, Stephen Worthington wrote:
>> On Tue, 7 Nov 2023 09:41:06 -0500, you wrote:
>>
>>> Just curious if this is possible...
>>>
>>> Let's say you have two mythboxes in different physical locations. Let's say
>>> a cottage or RV. At some point, you decide you'd like to have the
>>> recordings from box B on box A. Is it possible to import the recordings
>>> data into the database so that the recording info appears on box A?
>>>
>>> I realize that one could export the recordings as videos and just place
>>> them in the Video storage group, but if you want to import them into
>>> Recordings so you can easily edit them, is there a way to export/import
>>> their info from the database?
>>
>> Yes, that is what mythexport/mythimport does. Mythexport has a web
>> page that allows you to select the recordings to be exported, and
>> where to store the exported files. Each recording file is accompanied
>> by a .sql file with all the metadata from the database. Then
>> mythimport will read the .sql file and add it the destination
>> database, and move the recording file into a storage group directory.
>> I use this to export recordings from my main MythTV box to drives I
>> mount on my laptop, so I can take recordings away on holiday with me.
>>
>> Mythimport is easy to set up - just put its python file into
>> /usr/local/bin. Mythexport is rather more difficult now, as there are
>> no proper package files. I have not done it for ages, but if it still
>> works, you would download the mythexport package and do an "apt
>> install ./<package>.deb" command. Then you would need to download
>> some updated files and put them over the old files in the directories
>> they are installed in. Let me know if you would like to try this, and
>> I will get together the updated files and put them on my web server.
>>
>> I have also written a "mythsgu" program that has a command "mythsgu
>> exportdir" which creates all the export .sql files for mythimport to
>> use for an entire directory of recording files. Then you can use
>> "mythsgu copydir" to copy that directory over the network to the
>> destination PC or just simply copy the entire directory to a portable
>> drive and attach that to the destination PC. Then you can run
>> mythimport on the directory.
>>
>> http://www.jsw.gen.nz/mythtv/mythimport/mythimport
>> http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3.deb
>> http://www.jsw.gen.nz/mythtv/mythsgu
>>
>I would add that, since mythtv doesn't care which storage directory your recordings are in, it would
>be possible to move them /out/ from among the countless other recordings and place them into a
>separate directory before using mythsgu. Of course that new directory would have to be added as a
>recording storage group, at least for the life of the export process.

Yes, that is a way I have looked at. But the big problem with that
method is how you work out which recording file is which recording. So
it is easier to just use mythexport where you can select any number of
recordings from its web page and get them all copied (along with a
.sql file) to a different location.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 08 Nov 2023 04:33:27 +1300, you wrote:

>http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3.deb

Looks like I missed out a bit of the file name:

http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3_amd64.deb
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Nov 7, 2023 at 10:34?AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Tue, 7 Nov 2023 09:41:06 -0500, you wrote:
>
> >Just curious if this is possible...
> >
> >Let's say you have two mythboxes in different physical locations. Let's
> say
> >a cottage or RV. At some point, you decide you'd like to have the
> >recordings from box B on box A. Is it possible to import the recordings
> >data into the database so that the recording info appears on box A?
> >
> >I realize that one could export the recordings as videos and just place
> >them in the Video storage group, but if you want to import them into
> >Recordings so you can easily edit them, is there a way to export/import
> >their info from the database?
>
> Yes, that is what mythexport/mythimport does. Mythexport has a web
> page that allows you to select the recordings to be exported, and
> where to store the exported files. Each recording file is accompanied
> by a .sql file with all the metadata from the database. Then
> mythimport will read the .sql file and add it the destination
> database, and move the recording file into a storage group directory.
> I use this to export recordings from my main MythTV box to drives I
> mount on my laptop, so I can take recordings away on holiday with me.
>
> Mythimport is easy to set up - just put its python file into
> /usr/local/bin. Mythexport is rather more difficult now, as there are
> no proper package files. I have not done it for ages, but if it still
> works, you would download the mythexport package and do an "apt
> install ./<package>.deb" command. Then you would need to download
> some updated files and put them over the old files in the directories
> they are installed in. Let me know if you would like to try this, and
> I will get together the updated files and put them on my web server.
>
> I have also written a "mythsgu" program that has a command "mythsgu
> exportdir" which creates all the export .sql files for mythimport to
> use for an entire directory of recording files. Then you can use
> "mythsgu copydir" to copy that directory over the network to the
> destination PC or just simply copy the entire directory to a portable
> drive and attach that to the destination PC. Then you can run
> mythimport on the directory.
>
> http://www.jsw.gen.nz/mythtv/mythimport/mythimport
> http://www.jsw.gen.nz/mythtv/mythimport/mythexport_2.2.4-0ubuntu5-jsw3.deb
> http://www.jsw.gen.nz/mythtv/mythsgu


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.

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 8 Nov 2023, at 11:17 am, Stephen Worthington <stephen_agent@jsw.gen.nz> 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 offer not critique, ask lest I understand amis.
How does storing all your recordings in Watch Recordings not in Watch Videos offer you any benefit?
Do you cut commercials or just mark them and let mythtv do the magic ?
I find marking does not work eg if I watch on tv using UNLA. My wife uses an apple TV and I use mythtv for apple TV which also ignores cuts. Myth4Apple has another severe gotcha it does not see Videos, only Recordings, so being able to store recordings would help. I’ve not bothered to look, but I’ve no doubt mysql could help.

Another thing over the years chaos happens. Having a backup of Recordings-of-Interest is easier than a mythtv db dump that’s suddenly a few protocol revisions out of date.

Finally whatabout having Recordings and Videos share the same location ?

James


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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?

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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).
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi jam,

Wednesday, November 8, 2023, 9:44:24 AM, you wrote:

--snip--

> Finally whatabout having Recordings and Videos share the same location ?

> James

I do that all the time. After I have cut a recording I hardlink it to
it's real name in a special video directory and then import it into
the video system. Both have their (dis)advantages. I have this all
scripted.

One warning, this can mess-up diskspace management as deleting a
hardlinked file won't free any space until all links are deleted. But
I do not want those deleted so I see it as an extra safeguard. I
intent to move those recordings to a different disk that is not used
for recording, but I haven't come to that jet.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org