Mailing List Archive

mythcommflag vs mythtranscode for videos
Hello,
Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
mythcommflag --rebuild --video does not seem to be updating the
filemarkup table. Whenever I run it on mpeg4 .avi files, it shows
progress all the way through and then it reports the following at the end:

Rebuild completed at Thu Jan 3 17:15:04 2013
2013-01-03 17:15:04.334803 E decoding error
eno: Unknown error 541478725 (541478725)

Querying the filemarkup table for the file in question returns nothing
after this.

On the other hand, mythtranscode --buildindex --video seems to work
fine. It reports success, runs a lot faster, and when I query the
filemarkup table, I see a bunch of entries for the file I just rebuilt.

Is mythcommflag broken or is this functionality going away since
mythtranscode can do it?

Thanks,
Dave Hill





_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
> Hello,
> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that mythcommflag
> --rebuild --video does not seem to be updating the filemarkup table.
> Whenever I run it on mpeg4 .avi files, it shows progress all the way through
> and then it reports the following at the end:
>
> Rebuild completed at Thu Jan 3 17:15:04 2013
> 2013-01-03 17:15:04.334803 E decoding error
> eno: Unknown error 541478725 (541478725)
>
> Querying the filemarkup table for the file in question returns nothing after
> this.
>
> On the other hand, mythtranscode --buildindex --video seems to work fine.
> It reports success, runs a lot faster, and when I query the filemarkup
> table, I see a bunch of entries for the file I just rebuilt.
>
> Is mythcommflag broken or is this functionality going away since
> mythtranscode can do it?

Mythcommflag always produces that decoding error after completion,
which is just an artifact of the decoder reading EOF. So you can
ignore it.

I've found that mythcommflag can be sensitive about using absolute
versus relative pathnames for the video. If you use the absolute
pathname, it will happily insert filemarkup entries using the full
pathname in the filename column, but at playback it looks for filename
relative to the base of the storage group.

Jim
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
>> Hello,
>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that mythcommflag
>> --rebuild --video does not seem to be updating the filemarkup table.
>> Whenever I run it on mpeg4 .avi files, it shows progress all the way through
>> and then it reports the following at the end:
>>
>> Rebuild completed at Thu Jan 3 17:15:04 2013
>> 2013-01-03 17:15:04.334803 E decoding error
>> eno: Unknown error 541478725 (541478725)
>>
>> Querying the filemarkup table for the file in question returns nothing after
>> this.
>>
>> On the other hand, mythtranscode --buildindex --video seems to work fine.
>> It reports success, runs a lot faster, and when I query the filemarkup
>> table, I see a bunch of entries for the file I just rebuilt.
>>
>> Is mythcommflag broken or is this functionality going away since
>> mythtranscode can do it?
> Mythcommflag always produces that decoding error after completion,
> which is just an artifact of the decoder reading EOF. So you can
> ignore it.
>
> I've found that mythcommflag can be sensitive about using absolute
> versus relative pathnames for the video. If you use the absolute
> pathname, it will happily insert filemarkup entries using the full
> pathname in the filename column, but at playback it looks for filename
> relative to the base of the storage group.
>
> Jim
>

Thanks Jim, but it wasn't an issue of absolute vs relative pathnames --
I tried both, but I was searching for the base filename and it wasn't
there in the filemarkup table until I used mythtranscode to rebuild the
seek table.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 1/7/2013 10:33 AM, Dave Hill wrote:
> On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
>> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
>>> Hello,
>>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
>>> mythcommflag
>>> --rebuild --video does not seem to be updating the filemarkup table.

Could someone enlighten me as to the difference between these two commands?
- mythcommflag --rebuild --video <relative path>/<filename>
- mythtranscode --buildindex --video --infile <path>/<filename>

I thought I had read somewhere that they were equivalent, but I continue
to see that mythcommflag doesn't seem to update the filemarkup table
with any entries containing the filename in question. After running it,
I have dumped out the entire table grepping for the base filename and
found 0 entries. However, after running mythtranscode, I see 500+
entries in the filemarkup table for the file that was processed.

I'm running 2:0.26.0+fixes.20130126.14aa707-0ubuntu0mythbuntu1 and I
have lately been seeing issues seeking and/or saving bookmarks with SOME
of these files that had their seek tables built with mythtranscode. The
behavior I'm seeing is consistent with
http://code.mythtv.org/trac/ticket/11308 -- that suggests running
mythcommflag on the files in question. This appears to work to resolve
the seeking issues.

I've also found that videos that had their seek tables built with
mythtranscode (the ones that work) seem to seek "choppily" -- ie when I
Jump Ahead, the picture is very pixelated for a second or two -- where
if they were processed with mythcommflag, the seeking works fine.

Any information about how this works would be appreciated but I guess my
main question is -- is mythcommflag doing its work in a different db
table? Is there some way I can verify that a seek table was generated
after the mythcommflag --rebuild operation?

Thanks very much,
Dave Hill



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 01/29/2013 10:54 AM, Dave Hill wrote:
>
> On 1/7/2013 10:33 AM, Dave Hill wrote:
>> On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
>>> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
>>>> Hello,
>>>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
>>>> mythcommflag
>>>> --rebuild --video does not seem to be updating the filemarkup table.
>
> Could someone enlighten me as to the difference between these two
> commands?
> - mythcommflag --rebuild --video <relative path>/<filename>
> - mythtranscode --buildindex --video --infile <path>/<filename>
>
> I thought I had read somewhere that they were equivalent, but I
> continue to see that mythcommflag doesn't seem to update the
> filemarkup table with any entries containing the filename in
> question. After running it, I have dumped out the entire table
> grepping for the base filename and found 0 entries. However, after
> running mythtranscode, I see 500+ entries in the filemarkup table for
> the file that was processed.
>
> I'm running 2:0.26.0+fixes.20130126.14aa707-0ubuntu0mythbuntu1 and I
> have lately been seeing issues seeking and/or saving bookmarks with
> SOME of these files that had their seek tables built with
> mythtranscode. The behavior I'm seeing is consistent with
> http://code.mythtv.org/trac/ticket/11308 -- that suggests running
> mythcommflag on the files in question. This appears to work to resolve
> the seeking issues.
>
> I've also found that videos that had their seek tables built with
> mythtranscode (the ones that work) seem to seek "choppily" -- ie when
> I Jump Ahead, the picture is very pixelated for a second or two --
> where if they were processed with mythcommflag, the seeking works fine.
>
> Any information about how this works would be appreciated but I guess
> my main question is -- is mythcommflag doing its work in a different
> db table? Is there some way I can verify that a seek table was
> generated after the mythcommflag --rebuild operation?
>
> Thanks very much,
> Dave Hill
>
I am using mythcommflag and it seems that it actually deletes the seek
table, i.e. existing seek table is removed. This actually works quite
well, the transcoded file is an X264 mks file and seeking works
perfectly with no seek table. However if I do not run the mythcommflag,
the old seek table is still there, and seeking does not work at all,
trying to go forward or back stays in the same place and pixellates the
screen.

I am not sure why this is so, but it works for me. I thin perhaps x264
mks files do not need a seek table so the mythcommflag is removing it.

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On Tue, Jan 29, 2013 at 7:54 AM, Dave Hill <myth@davidrhill.com> wrote:
>
> On 1/7/2013 10:33 AM, Dave Hill wrote:
>>
>> On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
>>>
>>> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
>>>>
>>>> Hello,
>>>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
>>>> mythcommflag
>>>> --rebuild --video does not seem to be updating the filemarkup table.
>
>
> Could someone enlighten me as to the difference between these two commands?
> - mythcommflag --rebuild --video <relative path>/<filename>
> - mythtranscode --buildindex --video --infile <path>/<filename>
>
> I thought I had read somewhere that they were equivalent, but I continue to
> see that mythcommflag doesn't seem to update the filemarkup table with any
> entries containing the filename in question. After running it, I have
> dumped out the entire table grepping for the base filename and found 0
> entries. However, after running mythtranscode, I see 500+ entries in the
> filemarkup table for the file that was processed.
>
> I'm running 2:0.26.0+fixes.20130126.14aa707-0ubuntu0mythbuntu1 and I have
> lately been seeing issues seeking and/or saving bookmarks with SOME of these
> files that had their seek tables built with mythtranscode. The behavior I'm
> seeing is consistent with http://code.mythtv.org/trac/ticket/11308 -- that
> suggests running mythcommflag on the files in question. This appears to work
> to resolve the seeking issues.
>
> I've also found that videos that had their seek tables built with
> mythtranscode (the ones that work) seem to seek "choppily" -- ie when I Jump
> Ahead, the picture is very pixelated for a second or two -- where if they
> were processed with mythcommflag, the seeking works fine.
>
> Any information about how this works would be appreciated but I guess my
> main question is -- is mythcommflag doing its work in a different db table?
> Is there some way I can verify that a seek table was generated after the
> mythcommflag --rebuild operation?

All three tools (the recorder, mythcommflag --rebuild, and
mythtranscode --buildindex) produce seektables in the same place,
namely the recordedseek table for recordings and the filemarkup table
for videos. If mythcommflag is not producing any seektable entries,
one possibility is that the underlying ffmpeg is crashing on the file,
which is not unheard of. You might be able to detect this by running
it from the debugger. If not, it would help to get access to the
video file in question.

As for the "choppy seeks", is this from an HD-PVR recording? There
has been an issue where regenerating the seektable would identify
non-IDR I-frames whereas the recorder only identifies IDR frames.
That would likely lead to pixelation after a seek until an actual IDR
frame is reached. This issue was fixed in mythcommflag, but may still
be there in mythtranscode.

Jim
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 01/29/2013 04:31 PM, Peter Bennett (cats22) wrote:
> I am using mythcommflag and it seems that it actually deletes the seek
> table, i.e. existing seek table is removed. This actually works quite
> well, the transcoded file is an X264 mks file and seeking works
> perfectly with no seek table.

Yes, as a matter of fact, we don't support the bitstream format of MKV,
so you cannot create a seek table for MKV. (I'm assuming you mean MKV
for Matroska Video, as .mks would be Matroska Subtitle (only)).

> However if I do not run the mythcommflag,
> the old seek table is still there, and seeking does not work at all,
> trying to go forward or back stays in the same place and pixellates the
> screen.

Well, since we don't record to MKV, you must be creating the seek table
(which should not be there for MKV). Are you doing that with
mythtranscode after you transcode to MKV with some other utility? If
so, we need to fix mythtranscode to forbid creation of seek tables for MKV.

> I am not sure why this is so, but it works for me. I thin perhaps x264
> mks files do not need a seek table so the mythcommflag is removing it.
>

Or, really, we need to remove both mythtranscode --buildindex and
mythcommflag --rebuild and have only one approach for generating seek
tables (likely in mythutil's command interface).

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 1/29/2013 5:22 PM, Jim Stichnoth wrote:
> All three tools (the recorder, mythcommflag --rebuild, and
> mythtranscode --buildindex) produce seektables in the same place,
> namely the recordedseek table for recordings and the filemarkup table
> for videos. If mythcommflag is not producing any seektable entries,
> one possibility is that the underlying ffmpeg is crashing on the file,
> which is not unheard of. You might be able to detect this by running
> it from the debugger. If not, it would help to get access to the
> video file in question.
>
> As for the "choppy seeks", is this from an HD-PVR recording? There
> has been an issue where regenerating the seektable would identify
> non-IDR I-frames whereas the recorder only identifies IDR frames.
> That would likely lead to pixelation after a seek until an actual IDR
> frame is reached. This issue was fixed in mythcommflag, but may still
> be there in mythtranscode.
>
>
Thanks for the info Jim! No, these videos are all from DVD either using
mencoder 2-pass or mplayer to generate .vob and then ffmpeg 2-pass --
they are DIVX mpeg-4 .avi files. Every one that I tried had the
problem that mythcommflag does not generate filemarkup entries for
them. When I switched over to using mythtranscode to generate seek
tables, then I started noticing the other symptoms -- either seek
doesn't work at all or it is "choppy" when it works.

Running it under gdb, I saw two threads that exited before I saw the
progress indicator. Is one of those the underlying ffmpeg you referred to?

Reading symbols from /usr/bin/mythcommflag...(no debugging symbols
found)...done.
(gdb) run --rebuild --video DVDs/The_Truman_Show.avi
Starting program: /usr/bin/mythcommflag --rebuild --video
DVDs/The_Truman_Show.avi
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe00c6700 (LWP 18080)]
[New Thread 0x7fffdf8c5700 (LWP 18081)]
[New Thread 0x7fffdf0c4700 (LWP 18082)]
[New Thread 0x7fffde8c3700 (LWP 18083)]
[New Thread 0x7fffde0c2700 (LWP 18084)]
[New Thread 0x7fffdd8c1700 (LWP 18085)]
[New Thread 0x7fffdd0c0700 (LWP 18086)]
[New Thread 0x7fffcffff700 (LWP 18087)]
2013-01-29 18:39:21.134613 C mythcommflag version: fixes/0.26
[v0.26.0-89-g14aa707] www.mythtv.org
2013-01-29 18:39:21.134667 C Qt version: compile: 4.8.1, runtime: 4.8.1
[New Thread 0x7fffcf7fe700 (LWP 18088)]
[Thread 0x7fffcf7fe700 (LWP 18088) exited]
MythTV Commercial Flagger, building seek table for:
DVDs/The_Truman_Show.avi
[New Thread 0x7fffcf7fe700 (LWP 18089)]
[New Thread 0x7fffcd9ce700 (LWP 18090)]
Rebuild started at Tue Jan 29 18:39:21 2013
[New Thread 0x7fffbffff700 (LWP 18091)]
[Thread 0x7fffdd0c0700 (LWP 18086) exited]
2013-01-29 18:39:21.943303 E VDPAU: Error at mythrender_vdpau.cpp:1546
(#1, Unknown)
2013-01-29 18:39:21.943314 E VDPAU: Failed to create VDPAU device.
2013-01-29 18:39:21.943318 E VDPAU: No VDPAU device
2013-01-29 18:39:21.943321 E VDPAU: Failed to create dummy device.
2013-01-29 18:39:21.943554 E Object deleted with non-zero reference count!
Rebuild completed at Tue Jan 29 19:02:56 2013
2013-01-29 19:02:56.506857 E decoding error
eno: Unknown error 541478725 (541478725)
[Thread 0x7fffdf8c5700 (LWP 18081) exited]
[Thread 0x7fffdd8c1700 (LWP 18085) exited]
[Thread 0x7fffcd9ce700 (LWP 18090) exited]
[Thread 0x7fffdf0c4700 (LWP 18082) exited]
[Thread 0x7fffde8c3700 (LWP 18083) exited]
[Thread 0x7fffbffff700 (LWP 18091) exited]
[Thread 0x7fffde0c2700 (LWP 18084) exited]
[Thread 0x7fffcffff700 (LWP 18087) exited]
[Thread 0x7fffcf7fe700 (LWP 18089) exited]
[Thread 0x7fffe00c6700 (LWP 18080) exited]
[Inferior 1 (process 18075) exited normally]
(gdb) quit

It runs for about 20 minutes and then exits without generating a seek
table. What can I do to help diagnose this further?


Thanks,
Dave Hill



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On Tue, 2013-01-29 at 14:22 -0800, Jim Stichnoth wrote:
> On Tue, Jan 29, 2013 at 7:54 AM, Dave Hill <myth@davidrhill.com> wrote:
> >
> > On 1/7/2013 10:33 AM, Dave Hill wrote:
> >>
> >> On 1/4/2013 1:39 PM, Jim Stichnoth wrote:
> >>>
> >>> On Fri, Jan 4, 2013 at 7:49 AM, Dave Hill <myth@davidrhill.com> wrote:
> >>>>
> >>>> Hello,
> >>>> Running mythbuntu 12.04 / mythtv 0.26, I have been finding that
> >>>> mythcommflag
> >>>> --rebuild --video does not seem to be updating the filemarkup table.
> >
> >
> > Could someone enlighten me as to the difference between these two commands?
> > - mythcommflag --rebuild --video <relative path>/<filename>
> > - mythtranscode --buildindex --video --infile
> >
> >
> > I'm running 2:0.26.0+fixes.20130126.14aa707-0ubuntu0mythbuntu1 and I have
> > lately been seeing issues seeking and/or saving bookmarks with SOME of these
> > files that had their seek tables built with mythtranscode. The behavior I'm
> > seeing is consistent with http://code.mythtv.org/trac/ticket/11308 -- that
> > suggests running mythcommflag on the files in question. This appears to work
> > to resolve the seeking issues.
> >
> > I've also found that videos that had their seek tables built with
> > mythtranscode (the ones that work) seem to seek "choppily" -- ie when I Jump
> > Ahead, the picture is very pixelated for a second or two -- where if they
> > were processed with mythcommflag, the seeking works fine.
> >
> > Any information about how this works would be appreciated but I guess my
> > main question is -- is mythcommflag doing its work in a different db table?
> > Is there some way I can verify that a seek table was generated after the
> > mythcommflag --rebuild operation?
>
> All three tools (the recorder, mythcommflag --rebuild, and
> mythtranscode --buildindex) produce seektables in the same place,
> namely the recordedseek table for recordings and the filemarkup table
> for videos. If mythcommflag is not producing any seektable entries,
> one possibility is that the underlying ffmpeg is crashing on the file,
> which is not unheard of. You might be able to detect this by running
> it from the debugger. If not, it would help to get access to the
> video file in question.
>
> As for the "choppy seeks", is this from an HD-PVR recording? There
> has been an issue where regenerating the seektable would identify
> non-IDR I-frames whereas the recorder only identifies IDR frames.
> That would likely lead to pixelation after a seek until an actual IDR
> frame is reached. This issue was fixed in mythcommflag, but may still
> be there in mythtranscode.
>
> Jim

On my dirty 0.26_fixes..
"mythcommflag --rebuild --video" requires an absolute filepath.

mythcommflag removes any seektable on .mkv files in "Videos".
(No I-frames found, rewinding...)
mythtranscode creates a seektable for .mkv files & then this prevents
mythplayer working..

Fortunately .mkv files seek very well without a seektable.

Brett

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 01/29/2013 05:24 PM, Michael T. Dean wrote:
> On 01/29/2013 04:31 PM, Peter Bennett (cats22) wrote:
>> I am using mythcommflag and it seems that it actually deletes the seek
>> table, i.e. existing seek table is removed. This actually works quite
>> well, the transcoded file is an X264 mks file and seeking works
>> perfectly with no seek table.
>
> Yes, as a matter of fact, we don't support the bitstream format of
> MKV, so you cannot create a seek table for MKV. (I'm assuming you
> mean MKV for Matroska Video, as .mks would be Matroska Subtitle (only)).
>
>> However if I do not run the mythcommflag,
>> the old seek table is still there, and seeking does not work at all,
>> trying to go forward or back stays in the same place and pixellates the
>> screen.
>
> Well, since we don't record to MKV, you must be creating the seek
> table (which should not be there for MKV). Are you doing that with
> mythtranscode after you transcode to MKV with some other utility? If
> so, we need to fix mythtranscode to forbid creation of seek tables for
> MKV.
>
>> I am not sure why this is so, but it works for me. I thin perhaps x264
>> mks files do not need a seek table so the mythcommflag is removing it.
>>
>
> Or, really, we need to remove both mythtranscode --buildindex and
> mythcommflag --rebuild and have only one approach for generating seek
> tables (likely in mythutil's command interface).
>
> Mike
> _______________________________________________

Sorry - I do mean MKV, not mks. I am transcoding the MPG files to MKV
X264 (using handbrake), then updating the recorded table with the new
filename ending in MKV. After that I run mythcommflag --rebuild which
deletes the seek table entries. I suppose I could use a SQL command to
delete the seek table entries instead. As I mentioned, keeping the old
seek table entries causes problems with seeking, but deleting them
solves the problem.

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: mythcommflag vs mythtranscode for videos [ In reply to ]
On 01/29/2013 10:36 PM, Peter Bennett (cats22) wrote:
> On 01/29/2013 05:24 PM, Michael T. Dean wrote:
>> On 01/29/2013 04:31 PM, Peter Bennett (cats22) wrote:
>>> I am using mythcommflag and it seems that it actually deletes the seek
>>> table, i.e. existing seek table is removed. This actually works quite
>>> well, the transcoded file is an X264 mks file and seeking works
>>> perfectly with no seek table.
>> Yes, as a matter of fact, we don't support the bitstream format of
>> MKV, so you cannot create a seek table for MKV. (I'm assuming you
>> mean MKV for Matroska Video, as .mks would be Matroska Subtitle (only)).
>>
>>> However if I do not run the mythcommflag,
>>> the old seek table is still there, and seeking does not work at all,
>>> trying to go forward or back stays in the same place and pixellates the
>>> screen.
>> Well, since we don't record to MKV, you must be creating the seek
>> table (which should not be there for MKV). Are you doing that with
>> mythtranscode after you transcode to MKV with some other utility? If
>> so, we need to fix mythtranscode to forbid creation of seek tables for
>> MKV.
>>
>>> I am not sure why this is so, but it works for me. I thin perhaps x264
>>> mks files do not need a seek table so the mythcommflag is removing it.
>>>
>> Or, really, we need to remove both mythtranscode --buildindex and
>> mythcommflag --rebuild and have only one approach for generating seek
>> tables (likely in mythutil's command interface).
> Sorry - I do mean MKV, not mks. I am transcoding the MPG files to MKV
> X264 (using handbrake), then updating the recorded table with the new
> filename ending in MKV. After that I run mythcommflag --rebuild which
> deletes the seek table entries.

Ah, I see--you mean deleting the seektable entries for the
pre-transcoded recording MPEG.

> I suppose I could use a SQL command to
> delete the seek table entries instead. As I mentioned, keeping the old
> seek table entries causes problems with seeking, but deleting them
> solves the problem.

No, you're doing it exactly right. Using mythcommflag --rebuild to
remove the old seektable is the best way--regardless of what you've
transcoded to, since it will do the right thing for whatever video
type. I thought you were saying you were getting seektable entries for
the MKV, and I wanted to know where they were coming from so we could
fix whatever tool was putting them there. Thanks for explaining (and
sorry for the noise).

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users