Opened 14 years ago

Closed 14 years ago

#816 closed defect (fixed)

Bad seek tables

Reported by: stuart@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Several DVB (Mpeg2) recordings made with recent SVN have had bad/corrupt seek tables. There is no issue with the database or recordedmarkup table - they pass integrity checks. The table can be rebuilt fine with mythcommflag --rebuild.

I started to watch most several of the affected recordings whilst they were still in progress but at least one doesn't fit this pattern.

One other person on the Dev list has seen the problem, see the thread "A few potential bugs".

Unlike Mark I only noticed the issue within the last week of SVN.

Change History (7)

comment:1 Changed 14 years ago by anonymous

Summary: Bad seeks tablesBad seek tables

comment:2 Changed 14 years ago by tephra@…

Yep same here.

somewhere between 8210 -> 8272

Old DVB recordings work fine.

New ones can't seek properly, OSD seeking just displays 1 second, although after 30 mins of watching, a pause shows something like 2:53 (even though 30 mins has elapsed??) also FF seems to work, but when you un-FF you are actually more towards the start of the recording?!?!

Just confirming that there is a problem.

Cheers Dave

comment:3 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

What is the number of frames between keyframes in the seek table? If it is greater than 18, then this is probably a dupe of #799.

comment:4 Changed 14 years ago by anonymous

Well it isn't the same problem - but there _is_ a problem:

1083 2005-12-16 14:49:00 2105 368135020 9 1083 2005-12-16 14:49:00 2106 368291812 9 1083 2005-12-16 14:49:00 2107 368449168 9 1083 2005-12-16 14:49:00 2108 368644124 9 1083 2005-12-16 14:49:00 2109 368756924 9 1083 2005-12-16 14:49:00 2110 368931764 9 1083 2005-12-16 14:49:00 2111 369105288 9 1083 2005-12-16 14:49:00 2112 369285204 9 1083 2005-12-16 14:49:00 2113 369467188 9 1083 2005-12-16 14:49:00 2114 369633568 9 1083 2005-12-16 14:49:00 2115 369814800 9 1083 2005-12-16 14:49:00 2116 369999040 9 1083 2005-12-16 14:49:00 2117 370165420 9 1083 2005-12-16 14:49:00 2118 370334056 9 1083 2005-12-16 14:49:00 2119 370522056 9 1083 2005-12-16 14:49:00 2120 370717576 9

Assuming I'm understanding that correctly, every frame is being interpreted as a keyframe?

comment:5 Changed 14 years ago by danielk

Milestone: 0.19

Hmm, can you try the patch attached to 689 ?

comment:6 Changed 14 years ago by stuart@…

I might be speaking too soon, but it seems to work. I've tried three recordings on the most problematic channel and they have all been fine.

comment:7 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8290]) Fixes #689, fixes #816. Don't abort the scan for pictures too early...

Torbjorn Jansson actually reported to me that an earlier fix for #689 appeared to have worked for him. But this fixed a final problematic stream of David's so I'm closing this ticket with this commit. #816 appears to be a result of this same bit of code, basically if the picture code was transmitted too long after the seq or gop it wouldn't be found. This is sort of the exact opposite of the problem in #799.

Note: See TracTickets for help on using tickets.