Calculated current position deviates from actual position for H.264

[stuartm]

This is a recent bug, I guess either introduced somewhere in the last 6 weeks or caused by a change in the encoding of BBC HD.

After watching a recording for a period, the first seek made either through skip/jump or the editor is wildly wrong, most of the time several minutes later in the recording than it should be. Additionally the bookmark mark written to the database does not correspond to the actual location.

The symptoms initially suggest a bad seektable, such as the issue reported for #9126 so this may be a duplicate but the effects are different. I can seek around the recording with the editor and the byte offsets seem fine, the last frame in the table does seem to correspond to the end of the recording, the total recording length appears to be accurate unlike in #9126.

|  13940 | 2010-11-01 19:28:00 |    0 |      376 |    9 |
|  13940 | 2010-11-01 19:28:00 |   15 |   918192 |    9 |
|  13940 | 2010-11-01 19:28:00 |   35 |  1934144 |    9 |
|  13940 | 2010-11-01 19:28:00 |   51 |  2946712 |    9 |
|  13940 | 2010-11-01 19:28:00 |   64 |  3614864 |    9 |
|  13940 | 2010-11-01 19:28:00 |   73 |  4626304 |    9 |
|  13940 | 2010-11-01 19:28:00 |   82 |  5394848 |    9 |
|  13940 | 2010-11-01 19:28:00 |   91 |  6009796 |    9 |
|  13940 | 2010-11-01 19:28:00 |  100 |  6602560 |    9 |
|  13940 | 2010-11-01 19:28:00 |  109 |  7204348 |    9 |
|  13940 | 2010-11-01 19:28:00 |  118 |  7852572 |    9 |
|  13940 | 2010-11-01 19:28:00 |  126 |  8344192 |    9 |
|  13940 | 2010-11-01 19:28:00 |  137 |  8960268 |    9 |
|  13940 | 2010-11-01 19:28:00 |  146 |  9536300 |    9 |
|  13940 | 2010-11-01 19:28:00 |  155 | 10158016 |    9 |
|  13940 | 2010-11-01 19:28:00 |  164 | 10701336 |    9 |
|  13940 | 2010-11-01 19:28:00 |  173 | 11248416 |    9 |
|  13940 | 2010-11-01 19:28:00 |  181 | 11851332 |    9 |
|  13940 | 2010-11-01 19:28:00 |  190 | 12628712 |    9 |
|  13940 | 2010-11-01 19:28:00 |  199 | 13310776 |    9 |

The first 20 entries in the seektable show a variable frame distance, not a static one. The last mark in the table is 77263 with an offset of 6435781440. There are 5818 entries in total.

It's also possible that framesPlayed is bogus, not the seektable?

[beirdo]

Does a mythcommflag --rebuild significantly change the seek table? This might help us track down where the problem is.

[stuartm]

See #9126 - 'mythcommflag --rebuild' produces completely broken seektables that are different enough that seeking is not possible at all and the recording length is determined to be minutes instead of an hour.

I'll check whether the number of marks etc is consistent in a while, but I highly doubt it.

[robertm]

Beirdo, feel free to bounce this if it is not fixed by your dtvrecorder fixes.

[beirdo]

Although it is a newer ticket, this is basically the same as #9410, so let's close this one as the other has more details.