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

Hika van den Hoven hikavdh at gmail.com
Sun Jun 22 18:44:55 UTC 2014


Hoi Hika,

Sunday, June 22, 2014, 7:34:31 PM, you wrote:

> Hoi Mark,

> Sunday, June 22, 2014, 3:40:57 PM, you wrote:


>>> If you run mythcommflag without the --rebuild option, then you are
>>> doing the same thing as running it automatically at the time of the
>>> recording.  Without --rebuild, it does rebuild the recordedseek data,
>>> but also adds the commercial flagging data. 

>> My understanding if this must have been incorrect. I thought
>> --rebuild would rebuild the seek table but leave the commflag marks
>> untouched (which would then most likely be incorrect, depending on
>> circumstances). I though omitting the --rebuild would leave the seek
>> table untouched and only clear then redo the commflag marks.
>> _______________________________________________

> I discovered that bookmarks seem to stay valid after a rebuild. I've
> to test to be sure. I don't know if commflagging uses the same
> mechanism and what this further tells. To me it seems to imply that
> the to short recording length comes from an incomplete seek table
> build on recording, where the first part is correct and the second
> part missing. Although the bookmark I'm talking about was then in the
> missing part. (between the told end and the real end)


I have to adjust this. The bookmarks shoe the same shift as with
jumping, but they do stay. If watching an ongoing recording the shift
is already there. So my thought about the seek table being incomplete
is wrong.



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



More information about the mythtv-users mailing list