Mailing List Archive

MythArchive native mode 0.26-fixes
I would like to transfer a few recordings from one 0.26-fixes box to
another. In the past I could do this with MythArchive, although bitrot
has been progressing. In 0.26 the creation process has failed, ISTR,
with multi-word titles, but I have just tried a single-word title that
created the expected files. Now, on attempting import, I get another
classic helpful failure message:

CoreContext main.cpp:155 (copyFile) - Failed while running mythutil
--copyfile --infile /home/John/syncin/Horizon/1002_20130626195600.mpg
--outfile myth://Default@192.168.1.4:6543/1002_20130626195600.mpg.
Result: 128

Perhaps someone could interpret and suggest a course of action.

TIA

John P


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On Sat, 2013-07-27 at 23:26 +0100, John Pilkington wrote:
> I would like to transfer a few recordings from one 0.26-fixes box to
> another. In the past I could do this with MythArchive, although bitrot
> has been progressing. In 0.26 the creation process has failed, ISTR,
> with multi-word titles, but I have just tried a single-word title that
> created the expected files. Now, on attempting import, I get another
> classic helpful failure message:
>
> CoreContext main.cpp:155 (copyFile) - Failed while running mythutil
> --copyfile --infile /home/John/syncin/Horizon/1002_20130626195600.mpg
> --outfile myth://Default@192.168.1.4:6543/1002_20130626195600.mpg.
> Result: 128
>
> Perhaps someone could interpret and suggest a course of action.
>
> TIA
>
> John P


Root cause could be..the command line parsing of the program "mythutil"
changed sometime in 0.26 release..
The command line parsing now requires <space> to be escaped or wrapped
in quotes, previously the cmd options were delimited by --option_keyword
& not messed up by spaces.

I had to modify private scripts that utilize "mythutil" to allow passing
start-time info, part of that was <space> character(s).

Non-compiling workarounds:
- you can copy the failed cmd from log file & run it (mythutil) from a
terminal with quotes or escapes..
- could make a wrapper "fake mythutil" script that just adds the quotes
(for --outfile) & then calls "mythutil.real"

Attached a possible patch to the multi-word titles problem (that works
for me). The patch is from couple months ago..

Your import problem appears to be a permissions problem writing to
target ??

There was a mytharchive bug related to storage groups.

There was a mytharchive bug where it was messing up the seektable
output. This was caused by using the wrong DB fields.
http://www.gossamer-threads.com/lists/mythtv/commits/541033?search_string=mytharchive;#541033

B.
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 27/07/13 23:48, HP-mini wrote:

<snip>

Thanks for the reply. Rather embarrassingly, a retry after a reboot
seems to have worked. I'll try a few more tomorrow.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 27/07/13 23:56, John Pilkington wrote:
> On 27/07/13 23:48, HP-mini wrote:
>
> <snip>
>
> Thanks for the reply. Rather embarrassingly, a retry after a reboot
> seems to have worked. I'll try a few more tomorrow.
>

..but this is worrying: a few hours after MythArchive imported that
single recording, all recordings except the import and those made after
the MythArchive run appear to have lost their seektables.

I usually run mythcommflag --rebuild on individual recordings in a
script started from a terminal emulator. Hints about how to run it on
all recordings would be appreciated :-)

I did the reboot mentioned above because /dev/sr0 seemed to have gone
AWOL in the middle of a K3B disk-burning job; very unusual. It seems OK
now, but I had tried a 'new' brand of DVD+R not long before - Polaroid,
from ASDA, the UK version of Walmart. The first two samples both failed
to verify. They probably ran with different power settings, too, and I
wondered if the laser had overcooked. Back to Verbatim.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
> On 27/07/13 23:56, John Pilkington wrote:
> > On 27/07/13 23:48, HP-mini wrote:
> >
> > <snip>
> >
> ..but this is worrying: a few hours after MythArchive imported that
> single recording, all recordings except the import and those made after
> the MythArchive run appear to have lost their seektables.
>
Do you think the seektables are cleared or just wrong/offset?
How are you determining missing seektables ? Direct DB sql output?
H264 video?
There was a recent bug fix to H264parser/dtvrecorder that corrects the
seektable offsets..this might have got into 0.26+fixes.

I re-built all seektables & cut many recordings when it was discovered.

> I usually run mythcommflag --rebuild on individual recordings in a
> script started from a terminal emulator. Hints about how to run it on
> all recordings would be appreciated :-)
>
I just use "ls" & editor (search&replace) to generate a script..
Had to do this a couple of times in last 5-6 years.
B.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 28/07/13 20:57, HP-mini wrote:
> On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
>> On 27/07/13 23:56, John Pilkington wrote:
>>> On 27/07/13 23:48, HP-mini wrote:
>>>
>>> <snip>
>>>
>> ..but this is worrying: a few hours after MythArchive imported that
>> single recording, all recordings except the import and those made after
>> the MythArchive run appear to have lost their seektables.
>>
> Do you think the seektables are cleared or just wrong/offset?
> How are you determining missing seektables ? Direct DB sql output?
> H264 video?
> There was a recent bug fix to H264parser/dtvrecorder that corrects the
> seektable offsets..this might have got into 0.26+fixes.

All the recordings had been cut and remuxed to mpeg2 ps with mp2 audio.
On entering the editor, which I can usually use as a flexible skip
tool, they show 'no seektable'. I haven't looked directly at the DB.
>
> I re-built all seektables & cut many recordings when it was discovered.
>
>> I usually run mythcommflag --rebuild on individual recordings in a
>> script started from a terminal emulator. Hints about how to run it on
>> all recordings would be appreciated :-)
>>
> I just use "ls" & editor (search&replace) to generate a script..
> Had to do this a couple of times in last 5-6 years.
> B.

Yes, that should be easy enough; I just had vague memories of settings
that would process all recordings with one command, but I haven't found
the context yet. Thanks.

I'm reducing the number of my short recordings anyway, by concatenating
8 to 1 with a built-in rebuild, but it will be tedious if this happens
with every import. I haven't tried another one yet.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On Sun, 2013-07-28 at 21:34 +0100, John Pilkington wrote:
> On 28/07/13 20:57, HP-mini wrote:
> > On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
> >> On 27/07/13 23:56, John Pilkington wrote:
> >>> On 27/07/13 23:48, HP-mini wrote:
> >>>
> >>> <snip>
> >>>
> >> ..but this is worrying: a few hours after MythArchive imported that
> >> single recording, all recordings except the import and those made after
> >> the MythArchive run appear to have lost their seektables.
> >>


> On entering the editor, which I can usually use as a flexible skip
> tool, they show 'no seektable'. I haven't looked directly at the DB.


Can confirm that same is happening with latest master..test recording
was uncut mpegts.

>
> I'm reducing the number of my short recordings anyway, by concatenating
> 8 to 1 with a built-in rebuild, but it will be tedious if this happens
> with every import. I haven't tried another one yet.
>
Good idea.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 30/07/13 20:28, HP-mini wrote:
> On Sun, 2013-07-28 at 21:34 +0100, John Pilkington wrote:
>> On 28/07/13 20:57, HP-mini wrote:
>>> On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
>>>> On 27/07/13 23:56, John Pilkington wrote:
>>>>> On 27/07/13 23:48, HP-mini wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>> ..but this is worrying: a few hours after MythArchive imported that
>>>> single recording, all recordings except the import and those made after
>>>> the MythArchive run appear to have lost their seektables.
>>>>
>
>
>> On entering the editor, which I can usually use as a flexible skip
>> tool, they show 'no seektable'. I haven't looked directly at the DB.
>
>
> Can confirm that same is happening with latest master..test recording
> was uncut mpegts.
>
>>
>> I'm reducing the number of my short recordings anyway, by concatenating
>> 8 to 1 with a built-in rebuild, but it will be tedious if this happens
>> with every import. I haven't tried another one yet.
>>
> Good idea.
>

I've opened http://code.mythtv.org/trac/ticket/11712 after a second try
with the same result. I think the earlier copy failure happened because
I hadn't properly set the destination channel.

It all seemed to happen immediately. I get the impression that there's
a seektable switch attached to individual recordings, and that the
import resets them all. I would expect really deleting all the
seektables to be slower.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On Tue, 2013-07-30 at 21:50 +0100, John Pilkington wrote:
> On 30/07/13 20:28, HP-mini wrote:
> > On Sun, 2013-07-28 at 21:34 +0100, John Pilkington wrote:
> >> On 28/07/13 20:57, HP-mini wrote:
> >>> On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
> >>>> On 27/07/13 23:56, John Pilkington wrote:
> >>>>> On 27/07/13 23:48, HP-mini wrote:
> >>>>>
> >>>>> <snip>
> >>>>>
> >>>> ..but this is worrying: a few hours after MythArchive imported that
> >>>> single recording, all recordings except the import and those made after
> >>>> the MythArchive run appear to have lost their seektables.
> >>>>
> >
> >
> >> On entering the editor, which I can usually use as a flexible skip
> >> tool, they show 'no seektable'. I haven't looked directly at the DB.
> >
> >
> > Can confirm that same is happening with latest master..test recording
> > was uncut mpegts.
> >
> >>
> >> I'm reducing the number of my short recordings anyway, by concatenating
> >> 8 to 1 with a built-in rebuild, but it will be tedious if this happens
> >> with every import. I haven't tried another one yet.
> >>
> > Good idea.
> >
>
> I've opened http://code.mythtv.org/trac/ticket/11712 after a second try
> with the same result. I think the earlier copy failure happened because
> I hadn't properly set the destination channel.
>
> It all seemed to happen immediately. I get the impression that there's
> a seektable switch attached to individual recordings, and that the
> import resets them all. I would expect really deleting all the
> seektables to be slower.
>
> _
The mytharchivehelper (main.cpp) code (when importing native) checks for
existing recording of same name & existing recordedseek (DB table).
There must be something wrong with the SQL query so that it returns all
recordings & not just the ones that match chanID & startTime...

My "import" box only has 100 recordings & the seektables were gone in an
instant.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 30/07/13 22:11, HP-mini wrote:
> On Tue, 2013-07-30 at 21:50 +0100, John Pilkington wrote:
>> On 30/07/13 20:28, HP-mini wrote:
>>> On Sun, 2013-07-28 at 21:34 +0100, John Pilkington wrote:
>>>> On 28/07/13 20:57, HP-mini wrote:
>>>>> On Sun, 2013-07-28 at 10:49 +0100, John Pilkington wrote:
>>>>>> On 27/07/13 23:56, John Pilkington wrote:
>>>>>>> On 27/07/13 23:48, HP-mini wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>> ..but this is worrying: a few hours after MythArchive imported that
>>>>>> single recording, all recordings except the import and those made after
>>>>>> the MythArchive run appear to have lost their seektables.
>>>>>>
>>>
>>>> On entering the editor, which I can usually use as a flexible skip
>>>> tool, they show 'no seektable'. I haven't looked directly at the DB.
>>>
>>> Can confirm that same is happening with latest master..test recording
>>> was uncut mpegts.
>>>
>>>> I'm reducing the number of my short recordings anyway, by concatenating
>>>> 8 to 1 with a built-in rebuild, but it will be tedious if this happens
>>>> with every import. I haven't tried another one yet.
>>>>
>>> Good idea.
>>>
>> I've opened http://code.mythtv.org/trac/ticket/11712 after a second try
>> with the same result. I think the earlier copy failure happened because
>> I hadn't properly set the destination channel.
>>
>> It all seemed to happen immediately. I get the impression that there's
>> a seektable switch attached to individual recordings, and that the
>> import resets them all. I would expect really deleting all the
>> seektables to be slower.
>>
>> _
> The mytharchivehelper (main.cpp) code (when importing native) checks for
> existing recording of same name & existing recordedseek (DB table).
> There must be something wrong with the SQL query so that it returns all
> recordings & not just the ones that match chanID & startTime...
>
> My "import" box only has 100 recordings & the seektables were gone in an
> instant.
>
>


There's a couple of typo's in the two query's that removes the old
seektables in NativeArchive::importRecording(). I don't see how it would
cause the behaviour you describe though I would have thought the query's
would just fail to execute?

Paul H.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 30/07/13 21:50, John Pilkington wrote:
> On 30/07/13 20:28, HP-mini wrote:

>>>>>> <snip>
>>>>>>
>>>>> ..but this is worrying: a few hours after MythArchive imported that
>>>>> single recording, all recordings except the import and those made
>>>>> after
>>>>> the MythArchive run appear to have lost their seektables.
>>>>>
>>
>>
>>> On entering the editor, which I can usually use as a flexible skip
>>> tool, they show 'no seektable'. I haven't looked directly at the DB.
>>
>>
>> Can confirm that same is happening with latest master..test recording
>> was uncut mpegts.
>>
<snip.
>>
>
> I've opened http://code.mythtv.org/trac/ticket/11712 after a second try
> with the same result. I think the earlier copy failure happened because
> I hadn't properly set the destination channel.
>
> It all seemed to happen immediately. I get the impression that there's
> a seektable switch attached to individual recordings, and that the
> import resets them all. I would expect really deleting all the
> seektables to be slower.

That is probably incorrect: creating a seektable means reading the
entire recording, but deleting it would be much quicker.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 30/07/13 22:33, Paul Harrison wrote:
> On 30/07/13 22:11, HP-mini wrote:
>> The mytharchivehelper (main.cpp) code (when importing native) checks for
>> existing recording of same name & existing recordedseek (DB table).
>> There must be something wrong with the SQL query so that it returns all
>> recordings & not just the ones that match chanID & startTime...
>>
>> My "import" box only has 100 recordings & the seektables were gone in an
>> instant.
>>
>>
>
>
> There's a couple of typo's in the two query's that removes the old
> seektables in NativeArchive::importRecording(). I don't see how it
> would cause the behaviour you describe though I would have thought the
> query's would just fail to execute?
>
> Paul H.

This should be fixed in both 0.26-fixes and master.

Sorry for any inconvenience.

There is a patch on my fork that adds a new command to mythutil that
will check all your recordings and optionally fix any with missing seek
tables.

You can get the patch from here:-
https://github.com/paul-h/mythtv/commit/ea3dc2d7f5f00e96535e21006b4b810abd7ba9ad.patch

You would run it like this:-
mythutil -v none --checkrecordings --fixseektable

Paul H.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On Wed, 2013-07-31 at 19:59 +0100, Paul Harrison wrote:
> On 30/07/13 22:33, Paul Harrison wrote:
> > On 30/07/13 22:11, HP-mini wrote:
> >> The mytharchivehelper (main.cpp) code (when importing native) checks for
> >> existing recording of same name & existing recordedseek (DB table).
> >> There must be something wrong with the SQL query so that it returns all
> >> recordings & not just the ones that match chanID & startTime...
> >>
> > There's a couple of typo's in the two query's that removes the old
> > seektables in NativeArchive::importRecording(). I don't see how it
> > would cause the behaviour you describe though I would have thought the
> > query's would just fail to execute?

I stared at the code for 10 minutes & couldn't see it..

> Sorry for any inconvenience.

Not your fault..

>
> There is a patch on my fork that adds a new command to mythutil that
> will check all your recordings and optionally fix any with missing seek
> tables.
>

Does this also fix the space delimiting problem when mytharchivehelper
calls mythutil ?
(was patch in this thread)

> You can get the patch from here:-
> https://github.com/paul-h/mythtv/commit/ea3dc2d7f5f00e96535e21006b4b810abd7ba9ad.patch
>
> You would run it like this:-
> mythutil -v none --checkrecordings --fixseektable

Does this use the working "mythcommflag --rebuild" or the other ....

Thanks,
B.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: MythArchive native mode 0.26-fixes [ In reply to ]
On 31/07/13 20:17, HP-mini wrote:
> On Wed, 2013-07-31 at 19:59 +0100, Paul Harrison wrote:
>> There is a patch on my fork that adds a new command to mythutil that
>> will check all your recordings and optionally fix any with missing seek
>> tables.
>>
> Does this also fix the space delimiting problem when mytharchivehelper
> calls mythutil ?
> (was patch in this thread)

No I missed that. I'll take a look later.

>
>> You can get the patch from here:-
>> https://github.com/paul-h/mythtv/commit/ea3dc2d7f5f00e96535e21006b4b810abd7ba9ad.patch
>>
>> You would run it like this:-
>> mythutil -v none --checkrecordings --fixseektable
> Does this use the working "mythcommflag --rebuild" or the other ....

Yes it just calls mythcomflag --rebuild

Just realised it uses some stuff that I think is only available in
master so it probably wont compile on 0.26-fixes.

> Thanks,
> B.
>
>

Paul H.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users