Opened 8 years ago

Closed 7 years ago

#9176 closed defect (Duplicate)

Calculated current position deviates from actual position for H.264

Reported by: stuartm Owned by: beirdo
Priority: major Milestone: 0.24.1
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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?

Change History (5)

comment:1 Changed 8 years ago by beirdo

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

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by stuartm

Milestone: 0.240.24.1

comment:4 Changed 8 years ago by robertm

Owner: changed from jpoet to beirdo
Status: newassigned

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

comment:5 Changed 7 years ago by beirdo

Resolution: Duplicate
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.