[mythtv-users] mythcommflag corrupting recordings

[kanetse@gmail.com]

On Sat, Sep 13, 2008 at 2:26 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 09/13/2008 04:47 PM, kanetse wrote:
>> I believe that mythcommflag is corrupting my HD recordings.  If I have
>> an HD recording that is NOT commercial flagged, it is fine.  I can
>> skip back and forth and there are no problems in playback.  If I have
>> an HD recording that IS commercial flagged, playback is fine until I
>> skip forward or back.  Then playback has lots of stutter and does
>> audio and video goes out of sync.
>>
>> I was told that this might be due to corruption in the seektable, so I
>> followed the steps on this page:
>> http://www.mythtv.org/wiki/index.php/Repairing_the_Seektable (thanks
>> to Michael Dean).  When I re-ran mythcommflag, the problem was not
>> fixed.  However, if I run mythtranscode (following the parameters on
>> the above webpage), then the recording will playback properly.
>>
>> Anyone know what is wrong, or how I can fix this problem (other than
>> not-commerical flagging or transcoding every recording?).
>
> When you run mythtranscode as directed on that page (with --buildindex),
> you're not actually transcoding--similar to how when you run
> mythcommflag as directed on that page (with --rebuild), you're not
> actually flagging commercials.  Instead, both incantations simply tell
> whichever program (whose primary purpose is something else) to simply
> build a seektable for the show.  The code in mythcommflag that rebuilds
> seektables usually doesn't work on MPEG-2 (especially MPEG-2 from
> DVB/ATSC broadcasts), but the code in mythtranscode that rebuilds
> seektables probably(?) wouldn't work on NUV files.
>
>>   I don't
>> want to transcode every recording because I have plenty of disk space,
>> and sometimes I like to watch my recordings as they're being recorded,
>> about 20 minutes behind.
>>
>
> And, the ability to watch while recording is exactly why it's almost
> definitely not a problem with mythcommflag corrupting the seektable.
> While recording, the "NuppelVideoRecorder" builds the seektable.  The
> recorder knows the type of video being recorded, so it "knows" which
> code to run to properly build a seektable.
>
> Then, when mythcommflag is run by the backend, it simply flags
> commercials.  It doesn't erase/re-create or change the seektable that
> was built by the recorder.  Therefore, the seektable should be the same
> before and after mythcommflag runs.
>
> It is possible, though, that after running mythtranscode --buildindex,
> your seektable may change.  What would be interesting would be a chance
> to see the results of running the following in mysql on a recording that
> was recorded and not commflagged, then running a commflag (but not a
> "mythcommflag --rebuild" ; just give the chanid and starttime args and
> let it do a "normal" commflag), then re-running the following, then
> running a mythtranscode --buildindex, and, finally, re-running the
> following:
>
> tee /home/<user>/seektable-before.txt;
> SELECT mark, type, offset
>  FROM recordedseek
>  WHERE chanid = '<chanid>' AND starttime = 'YYYY-MM-DD hh:mm:ss';
> notee;
>
> Oh, and please make sure you change the name of the log file in the tee
> line for each re-run.  And, you'll need to specify an actual value for
> the <user>, <chanid>, and starttime
>
>> This is not a CPU-load problem - as I have tons of idle CPU.
>
> Yeah.  Though, with prebuffering pauses, there are plenty of causes
> besides CPU...
>
> I've actually tracked down the issue causing problems for me.  I haven't
> gotten a chance to fix it properly, but--in case it's helpful to you as
> another thing needing fixed, I'll mention the "high-level overview"--it
> turns out for me it's completely a (Linux) scheduler issue--I think the
> I/O scheduling specifically (though, as I said, I haven't tested the
> fixes to identify which part of the kernel's scheduling is causing the
> issue).  In my kernel upgrade to support the new AMD chipset, I went
> from noop to cfq scheduler.  I'll be playing with ionice'ing the process
> that's conflicting and, if all else fails, probably just go back to noop.
>
> I'm pretty sure all of what I said about the functioning of seektable
> building and automatically flagging commercials is correct, though I
> didn't get a chance to look through the code (after all, I haven't even
> had a chance to fix my own Myth frontend, yet :).  However, I trust that
> Chris Pinkham (now that I've mentioned his name) will see this post and
> let us know what parts I got wrong.
>

Grrrr... so I stand corrected.  Apparently it has nothing to do with
commercial flagging, but rather depends on what HD channel the show
was recorded on.  Discovery Canada HD - has no problems, even after
commflagging.  Yet, Chicago CW HD, seems to be bad right after
recording even before any commercial flagging has taken place.