[mythtv-users] 0.27.1 stores wrong length in SD mpeg2 recordings

[Hika van den Hoven]

Hoi Hika,

Saturday, June 21, 2014, 8:36:16 PM, you wrote:

> Hoi Stephen,

> Saturday, June 21, 2014, 12:48:05 PM, you wrote:

>> On Sat, 21 Jun 2014 01:41:23 +0200, you wrote:

>>>Hoi Discussion,
>>>
>>>About a month ago a moved from 0.26 to 0.27 and then 0.27.1.
>>>Since then I have a problem with my recordings. I only record SD with
>>>a PVR350 and a PVR500, so hardware mpeg2 recorders.
>>>Here some statistics from first 0.26
>>>recorded from till shown length on playback
>>>     18:35-20:20   1:44:59
>>>     20:05-21:50   1:44:57
>>>     18:35-20:20   1:44:59
>>>and recent recordings
>>>     19:00-20:45   1:31:32
>>>     18:00-18:31   0:27:07
>>>      9:04-10:15   1:04:03
>>>As you see the shown length is 10 to 13% to short and also has nothing
>>>to do with the show length, which often is about that much shorter,
>>>but not for the fifth recording. (30 min)
>>>
>>>I first noticed it because if I jumped back a little (I have left set
>>>to jump back 10s and right to forward 1 min) I jumped forward one to
>>>several minutes. Depending on how far I was in the recording and the
>>>time since the last jump. If the recording comes at the end of the
>>>shown length it plays on till the real end.
>>>Also commercial flagging is screwed up by this.
>>>If I transcode either inside to nuv or outside by way of dv back to
>>>mpeg2 (I use kino to remove commercials. The resulting mpeg2 file is
>>>half the size without noticeable quality loss) the problem is gone.
>>>
>>>The problem exists only with recordings under 0.27/0.27.1.

>> I had problems with skipping like that (in 0.26?), but the opposite
>> way around, with my older PVR-500 recordings.  As best I can recall,
>> the skipping worked much as you are describing.  I am not sure what
>> version it started with, but what I had to do was make myself a User
>> Job ("Rebuild seek table"):

>>   mythcommflag --rebuild -f %FILE%

>> If I run that on an old recording, then the skipping works properly
>> again.  I never did any research on it, but I just assumed that how
>> the seek table data worked had been changed in the new version and it
>> needed to be re-created.  Fortunately, my new MythTV box is quite fast
>> and I can run that job on an old file in less than a minute.

>> I have no idea how PVR-500 recordings work in 0.27 as I do not use my
>> PVR-500 any more. I am now recording digitally from the channels I
>> used to use the S-Video output from my STB for.  I can not remember
>> for sure if new PVR-500 recordings worked OK or not - the change to
>> digital recording happened about the same time as I noticed this
>> problem.  But I think they were OK.

>> I just checked an older PVR-500 recording that I have never rebuilt
>> the seek table for and it shows the length on playback to be over 27
>> hours, for a 1h02m recording.  That does not seem to be quite the same
>> as what you are seeing.
>> _______________________________________________

> Thanks for the input. I will try that mythcommflag command somewhere
> this evening. Startrek Generations is recording now and I don't want
> to disturb that, so I have to be careful.

>> Start mplayer with  -demuxer lavf
> This runs OK but I can't get much more info. mplayer just starts with
> a viewing window and no controls or menu. The console output is
> in dutch so I have to translate before posting. It also doesn't give
> any real interesting info, except again "first frame is no keyframe"

>> Your last point may imply that the file is being incorrectly labeled as mpeg-ps
>> when it should be mpeg-ts. TS (Transport Stream), being indeterminate, can start
>> anywhere whereas a PS (Program Stream) would be expected to begin on a keyframe.
> While investigating this issue I have noticed that ps/ts is one of the
> view things you can set in the recording profile for hardware mpeg2.
> It is set to ps and as far as I can remember that was originally last
> year when I started with myth the default. As far as I can remember I
> haven't touched it before. Could it be that changing this in the
> profile could help?

> Where and when is this seektable info stored, for in recorded there is just
> start and finish time.
> As said before I do commercial cutting outside myth and haven't had
> any problem with it. I adjust progendtime and filesize and sync
> start/endtime to progstart/endtime. No problems encountered so far
> with that. Actually the above problem is gone after that.

> Tot mails,
>   Hika                            mailto:hikavdh at gmail.com

An update.
transcoding in this case is really dangerous. Transcoding stops at the
perceived end of the recording and it is truncated.
mythcommflag --rebuild -f %FILE% works. I tested a file at the command
line and it now shows the correct duration. It however gave a decoding
error after finnishing: Unknown Error 541478725.

So to me it's still unclear whether the fault lies in the recording
or in the recording processing by myth. Even if it is in the file, the
header is processed by myth. If any more info could help determining,
please ask.


Tot mails,
  Hika                            mailto:hikavdh at 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