Opened 18 years ago
Closed 18 years ago
#816 closed defect (fixed)
Bad seek tables
Reported by: | 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 18 years ago by
Summary: | Bad seeks tables → Bad seek tables |
---|
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
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 18 years ago by
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:6 Changed 18 years ago by
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 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(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.
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