mpeg2 seektable generators are inconsistent

[J.Pilk@…]

mythtv-0.25-283_v0.25_rc_156_g02216ca.el6.rpm fromATrpms

Seektables generated during recording, or by mythcommflag --rebuild, or by mythtranscode --mpeg2 --buildindex, are not the same. I demonstrated this by making MythArchives? of a short recording 'raw' and after running each command, and examining the .xml files created. The mythcommflag version does not include a mark=0 entry and the offsets (byte positions) from both commflag and transcode are then consistently 188 bytes greater than the 'raw' value. Maybe a within-packet offset got counted twice?

This was a recording from dvb-t. I'll check to see if HD dvb-t2 recordings show a similar raw/mythcommflag discrepancy.

raw <recordedseek>

<mark offset="188" type="9" mark="0"/> <mark offset="461164" type="9" mark="30"/>

mythcommflag <recordedseek>

<mark offset="461352" type="9" mark="30"/> <mark offset="812724" type="9" mark="60"/>

mythtranscode <recordedseek>

<mark offset="376" type="9" mark="0"/> <mark offset="461352" type="9" mark="30"/>

[J.Pilk@…]

With dvb-t2 HD recording: here the discrepancy in frame numbering is a complete keyframe interval. FWIW the recording was started mid-programme, from the EPG screen.

raw:

<channel callsign="Channel 4 HD" channum="52" chanid="1052" name="Channel 4 HD"/> <recordedseek>

<mark offset="376" type="9" mark="0"/> <mark offset="427512" type="9" mark="24"/> <mark offset="1044904" type="9" mark="48"/> <mark offset="1654400" type="9" mark="72"/> <mark offset="2244720" type="9" mark="96"/>

commflag:

<channel callsign="Channel 4 HD" channum="52" chanid="1052" name="Channel 4 HD"/>

<recordedseek>

<mark offset="1044904" type="9" mark="24"/> <mark offset="1654400" type="9" mark="48"/> <mark offset="2244720" type="9" mark="72"/> <mark offset="2847636" type="9" mark="96"/> <mark offset="3454312" type="9" mark="120"/>

[beirdo]

I'll take a look at this.

[J.Pilk@…]

Thanks for that. This is relevant too. ​http://code.mythtv.org/trac/ticket/10606#comment:4

[sphery]

FWIW, we should probably remove one or both of mythtranscode --buildindex and mythcommflag --rebuild (if removing both, the functionality would go into mythutil, instead--since rebuilding the seek data is neither transcoding the recording nor flagging commercials).

[J.Pilk@…]

More observations on this here:

​http://www.gossamer-threads.com/lists/mythtv/users/520055#520055

[Jim Stichnoth]

This is most likely fixed as a result of commits related to #11328. If there are still problems in 0.26 related to the recorder seektable, then it is probably a dup of #11459.