[mythtv-users] Re: Fast Fowarding Lines in captured video?

[Chad]

On 8/23/05, Chad <masterclc at gmail.com> wrote:
> On 8/23/05, Ryan Steffes <rbsteffes at gmail.com> wrote:
> >
> >
> > >
> > > Or direct links to the 2:
> > > http://curvins.com/myth/ffwd-lines-5MB.avi
> > > http://curvins.com/myth/ffwd-lines-end-5MB.avi
> > >
> > > If anyone can offer any feedback, it would be much appreciated.  I
> > > have ruled out a single channel, the clip is from DragonBall Z (my
> > > brother loves the show :) ) recorded from Cartoon Network.  So it's
> > > SpikeTV and Cartoon Network so far, I don't record much else, but it
> > > would seem to not be a channel issue at this point.
> > > ________________________
> > >
> > >
> >
> >
> > Have you tried fine tuning the channels?  Are you getting any errors in
> > dmesg from the video driver or in the backend logs?  It almost looks like
> > you are losing the channel lock.
> >
> > Ryan
> >
> > _______________________________________________
> 
> I haven't actually.  But...  The channels are analog cable.  It's not
> specific to any channel, it happens on any recording, and seems to be
> happening more and more often on nearly every recording.  I get a
> great image on regular TV when I watch it (not fed through the
> computer, just plugged directly into a TV) and this never happens.
> 
> I'll give that a try though, I will also try switching out any other
> cables that I have for RG6-Quad and quality connectors just to rule
> that out as well.
> 
> Any other suggestions are welcome, I'm really stumped.  I'll probably
> upgrade my kernel to see if that does anything (the bttv driver is
> from my kernel).  I haven't seen anything in any logs, not the backend
> log, nor my kernel logs, but I'll look em over again to see if I
> missed something.
> 
> Thanks again!
> 

Woohoo!  Well sorta...

So I finally was able to find something, and after some googling, I'm
not a lot further, but at least I can identify the problem.  Here's
the error as reported in dmesg:

bttv0: PLL can sleep, using XTAL (28636363).
bttv1: PLL can sleep, using XTAL (28636363).
bttv1: OCERR @ 3e5c5014,bits: HSYNC OFLOW FBUS OCERR*
bttv1: OCERR @ 3e5c5014,bits: HSYNC OFLOW FBUS OCERR*
bttv1: OCERR @ 3e5c501c,bits: HSYNC OFLOW FBUS OCERR*
bttv1: OCERR @ 3e5c5014,bits: HSYNC OFLOW OCERR*
bttv1: OCERR @ 3e5c501c,bits: HSYNC OFLOW FBUS OCERR*
bttv1: OCERR @ 3e5c501c,bits: HSYNC OFLOW FBUS OCERR*
bttv1: OCERR @ 3e5c501c,bits: HSYNC OFLOW FBUS OCERR*


And it just continues like that for a long long time.  The first 2
lines are only there once, so I figure they may be of some importance.
 I'm going to try booting with the option=noacpi and see if that does
anything.

In the meantime, if anyone has any suggestions, please reply!  :)

Thanks!