[mythtv-users] Seek table rebuilding for MPEG-2 broken in 0.18.1, alas

Yeechang Lee ylee at pobox.com
Mon Feb 13 05:47:25 UTC 2006


Boleslaw Ciesielski <bolek-mythtv at curl.com> wrote:
> "mythcommflag --rebuild" is partially broken (also in 0.19), see
> http://svn.mythtv.org/trac/ticket/1088 In 0.19 you can use
> "mythtranscode -b" as a workaround.

but, Kevin Kuphal <kuphal at dls.net> says:
> --rebuild doesn't rebuild in 0.18 unless the seektable is not
> present at all.  This is fixed in 0.19.  You can workaround in 0.18
> by removing the seektable from the database prior to running
> mythcommflag --rebuild

Alas, the two of you are disagreeing here.

Boleslaw, I just tried running 'mythtranscode -b c 1173 -s
2005-12-19-150000 --showprogress' and got the following, then the
command line, within a half second:

    adding pes stream at pid 0x31 with type 2
    adding pes stream at pid 0x34 with type 129

I am not in the position of being able to test the file at this time,
but I recall seeing similar messages when running 'mythcommflag
--rebuild' on the same nuv file (although it chugged away for several
minutes--as noted, fruitlessly so--before completing).

Kevin, I'm puzzled by your first statement because, as I mentioned in
my original message, the recordings I'm hoping to rebuild the seek
tables for I added back into a new database after losing the old
database completely; therefore they shouldn't have preexisting seek
tables at all. Does Myth automatically build seek table data of any
kind for a recording when viewed with the frontend? If so, perhaps I
should try 'mythcommflag --rebuild' on a recording I've added but
didn't try viewing with the frontend. (If this does work, what's a
good way to delete any problematic "stub" seek table data in the
database? My ignorance of SQL knows no bounds.)

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


More information about the mythtv-users mailing list