[mythtv-users] mythcommflag corrupting recordings

[Michael T. Dean]

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.

Mike