[mythtv-users] 0.19 longer than 1 hr recordings seektable off?

[Yeechang Lee]

Steven Adeff <adeffs.mythtv at gmail.com> says:
> Recorded the 2 hr American Idol and now with the Olympics, both in
> HD, I'm noticing that the seektable is far off and doesn't allow for
> seeking.

Given that you wrote this on Thursday my guess is you recorded these
programs simultaneously.

I've recorded dozens of hours of HDTV recordings since 0.19 with the
same reliable seek tables as with 0.18.1. I can't say what happened in
your case (Did MySQL hang during the recording process? Are these
transcoded recordings?  Etc., etc.), but . . .

> So I tried running mythcommflag --rebuild which allows me to skip
> sorta, but the seektable is still wrong so it jumps to weird points
> and doesn't fastforward properly.

As I noted in
<URL:http://www.gossamer-threads.com/lists/mythtv/users/181802?search_string=yeechang%20mythcommflag;#181802>,
'mythcommflag --rebuild -f xyz.mpg' just didn't work, period, in
0.18.1. Then, as I noted in
<URL:http://www.gossamer-threads.com/lists/mythtv/users/183846?search_string=yeechang%20mythcommflag;#183846>,
the same command in 0.19 produced for me the same bizarre results as
you saw.

As my second message mentions, the only proper solution I've found is

'mythtranscode --mpeg2 --infile xyz.nuv --buildindex --showprogress'

Although much slower than 'mythcommflag --rebuild -f' (Although how
can you really compare the speeds between something that works and
something that essentially doesn't? A rather metaphysical question,
no?), I was too pessimistic when citing its speed for HDTV recordings;
I've found that a 90-minute movie (about 10GB if recorded off one of
the high-compression, low-bandwidth premium movie channels) gets done
in 20-30 minutes on a lightly-loaded 2.8-3GHz Pentium 4 or Xeon.

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US