Modify

Opened 7 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?

Attachments (0)

Change History (5)

comment:1 Changed 7 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 7 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 7 years ago by stuartm

  • Milestone changed from 0.24 to 0.24.1

comment:4 Changed 7 years ago by robertm

  • Owner changed from jpoet to beirdo
  • Status changed from new to assigned

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

comment:5 Changed 7 years ago by beirdo

  • Resolution set to Duplicate
  • Status changed from assigned to closed

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.

Add Comment

Modify Ticket

Action
as closed The owner will remain beirdo.
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.