[mythtv] Random blockiness that probably isn't CPU or PCI bus bandwidth-related

[John Patrick Poet]

Eric Anderson wrote:

>
> Kyle -
>
> I have been seeing a very similar problem on my system (2.6-GHz 
> hyperthreaded P4)
> with two HD-3000 cards. And it doesn't happen every time. It actually 
> seems to happen
> more often with the latest CVS (with John Poet's ringbuffer code). 
> With my own version
> of the ringbuffer code substituted, it happens a lot less.  I'm not 
> sure why. With the latest
> CVS, it happens maybe 1 out of 5 recordings or so? With my version of 
> the ringbuffer
> code, maybe 1 time out of 20-30 recordings. (Hard to say, haven't seen 
> it that often
> lately.)



I am seeing an occasional buffer overrun lately.  I am not sure why, 
since I was not seeing them a couple of weeks ago.  Maybe I subtly broke 
something when I moved the ringbuffer from the DTV class to the HDTV 
class...

> [I'll attach my version of the ringbuffer if you want to try it... 
> John has claimed he wasn't
> able to get the performance he needed for recording with 3 cards 
> without using a highly
> tuned version, but I'm not sure if he ever tried my final version of 
> the ringbuffer. One
> difference is that my version uses a single wrap-around buffer and 
> works out of that
> buffer -- in an attempt to reduce the number of extra copies.]


I have not tried your latest version.  When I tried to remove the 
"double buffering" when reading from the ringbuffer, I needed to greatly 
increase the ringbuffer to get it to work as well.  I also never 
increased the internal buffer size in the HD-x000 driver -- maybe that 
is why my results differed from yours.  If I have time this weekend, I 
will try your latest version.  I assume it applies to the latest CVS?

>
> When the bug occurs, data starts being corrupted part way through a 
> recording. And
> it continues to be corrupted pretty much until the end of the 
> recording. I was wondering
> exactly what was broken in the recording...

<snip>

>
> My particulars:
>
>    Fedora Core 2 - Kernel rev  2.6.5
>    HD3000  driver rev 1.4   (Note: I tweaked the buffer size in 
> cx88-atsc.c to
>                                                  be 188*1536 instead 
> of 188*512. And I disabled
>                                                  the audio thread in 
> cx88-video.c that just prints
>                                                  messages and doesn't 
> seem to do anything else. I still need
>                                                  to try reverting this 
> to a stock version to see if it helps.)
>   Latest myth CVS (w/ John Poet's ringbuffer code)  -- seems to happen 
> more often with this
>   Latest myth CVS (w/ my version of ringbuffer code)  -- I've seen 
> this only once in the last week
>   Pentium 4 @ 2.6-GHz Hyperthreading enabled
>   2 x HD3000 cards
>   1 x Sony gigapocket tuner card (using ivtv) -- not recording when 
> this bug occurs


Have you tried the v1.6 driver?  It seems to work well for me -- 
although it may be why I see an occasional overrun now, when I didn't a 
couple of weeks ago (I was using the 1.5 driver).

>
> Attachments:
>            xsum188.c -- in case you want to analyze a corrupted stream.
>            diffs             -- My diffs for HD3000 rev 1.4.
>
> The next thing I was going to do was try to add some instrumentation 
> code to the
> HD3000 driver. Because I *think* the card and/or driver are getting 
> into a bad state
> at some point which is causing all of these overruns; and it doesn't 
> recover for the
> duration of the recording.
>
> Note: I don't even lose packet sync. It's just packets clobbering 
> other packets. (Which
> is consistent with data being clobbered in the driver, because the 
> driver deals with
> multiples of 188-bytes internally.)


Maybe increasing the internal buffer size in the HD3000 driver is 
causing a problem?  Probably not.  I have seen the corruption you are 
talking about, but not in several weeks.  That is why I think it may be 
fixed in the 1.6 driver.

John