[mythtv-commits] Ticket #7978: Seektable built during recording is broken; fixed by rebuilding seektable

[MythTV]

#7978: Seektable built during recording is broken; fixed by rebuilding seektable
---------------------------------------------+------------------------------
 Reporter:  Ian Macdonald <ian@…>            |        Owner:  ijr       
     Type:  defect                           |       Status:  new       
 Priority:  major                            |    Milestone:  0.24      
Component:  MythTV - General                 |      Version:  0.22-fixes
 Severity:  medium                           |   Resolution:            
  Mlocked:  0                                |  
---------------------------------------------+------------------------------

Comment(by OliHenning):

 Ok, there, i can also confirm this problem.

 I have a Hauppauge PVR-500 (double-Tuner, Analog-TV, OnBoard-MPEG-Enocder)
 I'm in Switzerland, so i'm using PAL 50HZ.

 I analyzed a bit and observed, that mythbackend is making entries in the
 MySQL-Table "recordedseek" '''while''' the recording is running. It makes
 seek-entries of type '9' which means 'GOP' (Group of Pictures).

 Info: With this Information in the table, mythfrontend is able to seek
 quickly to a specific timepoint in a recording, as every MPEG-Decoding has
 to start at the beginning of a GOP (we have to hit the 'exact' Byte-
 Position in the Multi-100-Megabytes-MPEG-File !).
 Additionally, mythfrontend can quickly calculate the length of the movie
 in hh:mm:ss (simply make a
 {{{
 SELECT max(mark) FROM seektable WHERE type=9 AND chanid=... AND
 starttime=...
 }}}
  or so)

 '''BUT:''' These seektable-entries 'while-recording' are wrong. I dumped
 the entries of a recording right after the recording, then i did a rebuild
 of these seek-entries as follows:

 {{{
 mythtranscode -b -i 1004_20100731012300.mpg
 }}}

 and then i dumped the entries again. And there are differendes:

 After ''Recording'': 3936 Rows[[BR]]
 After ''Transcode'': 3996 Rows

 After ''Recording'': mark-values (=25Hz Frames) from 0 to 47403[[BR]]
 After ''Transcode'': mark-values (=25Hz Frames) from 0 to 47940

 After ''Recording'': Recording-Length min:sec = 31:34 (=47403/25
 Seconds)[[BR]]
 After ''Transcode'': Recording-Length min:sec = 31:56 (=47940/25 Seconds)

 After ''Recording'': delta between two mark-values: random (between 1 and
 42, but mostly 12)[[BR]]
 After ''Transcode'': delta between two mark-values: ALWAYS 12


 So, in my optinion, mythbackend (while recording running) is not able to
 identify the GOP-Frames in the MPEG-Stream correctly while mythtranscode
 does.

 what do you mean

 Greeting from switzerland

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/7978#comment:10>
MythTV <http://www.mythtv.org/>
MythTV