[mythtv-users] mythcommflag corrupting recordings
Michael T. Dean
mtdean at thirdcontact.com
Sat Sep 13 21:26:36 UTC 2008
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
More information about the mythtv-users
mailing list