<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br><br>> From: awalls@radix.net<br>> To: ivtv-users@ivtvdriver.org<br>> Date: Sat, 13 Feb 2010 15:54:23 -0500<br>> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame<br>> <br>> On Sat, 2010-02-13 at 14:32 -0500, Devin Heitmueller wrote:<br>> > On Sat, Feb 13, 2010 at 1:35 PM, Kyle Lil <kpl388@msn.com> wrote:<br>> > > The hard drive is being accessed pretty frequently (~1/second) when watching<br>> > > tv with mythtv, much more often than the errors are appearing. So, the hard<br>> > > drive cannot reliably produce the errors. Interestingly, I think the errors<br>> > > seem to occur slightly more often when watching tv with myth than when just<br>> > > monitoring the signal with azap. Would azap catch all errors or does it just<br>> > > sparsely sample the signal?<br>> > > The optical drive is not spinning up and the graphics card is fanless. The<br>> > > only other significant EMI sources inside the computer that I can think of<br>> > > are the case fan, cpu fan, and maybe the power supply. I can play around<br>> > > with different ground configurations to see if that helps.<br>> > <br>> > Kyle,<br>> > <br>> > Just to be clear, the BER/UNC counters count the number of errors<br>> > *only* between the tuner and demodulator. These are errors where the<br>> > Reed-Solomon error correction built into the signal could not<br>> > compensate (essentially errors in the analog signal transmission).<br>> > I'm pointing this out to make clear that those counters do not track<br>> > any *other* possible class of problem,<br>> <br>> Devin,<br>> <br>> Right. My statement about EMI was that signals inside the computer are<br>> affecting the IF signal on the card.<br>> <br>> (Sometime back on a list that I monitor, I recall someone with a disk<br>> controller right next to their TV capture card causing problems. Moving<br>> the TV card away from the disk controller card fixed the issue.)<br>> <br>> Since SNR wasn't really changing for Kyle, my guess was the errors come<br>> from strong "narrowband" and/or "burst" noise superimposed onto the IF<br>> from within his computer. Since the operation of the computer internals<br>> could easily behave differently between Windows and Linux, this seemed<br>> plausible to explain different results between Linux to Windows.<br>> <br>> <br>> The SNR reported for QAM is just a conversion from an averaged quantity<br>> being reported by the chip. I suppose the averaging interval could be<br>> hiding actual error bursts coming down the cable, so we never see SNR<br>> dip. However that would not explain why he didn't notice any video<br>> defects under Windows (assuming the Windows rendering app and linux<br>> rendering app handle errors in the same way).<br>> <br>> <br>> <br>> > such as packets being lost in<br>> > the cx18 driver, the application's failure to read the packets from<br>> > the driver fast enough (resulting in the packets being dropped by the<br>> > driver), or problems writing the MPEG frames to the hard disk, etc.<br>> <br>> My suggestion was more about disk activity causing EMI internal to the<br>> PC case. I had in mind perhaps a disk controller card next to the<br>> HVR-1600.<br>> <br>> Regards,<br>> Andy<br>> <br>> > Devin<br>> <br>> <br>> <br>> _______________________________________________<br>> ivtv-users mailing list<br>> ivtv-users@ivtvdriver.org<br>> http://ivtvdriver.org/mailman/listinfo/ivtv-users<br><div><br></div><div>Thanks Devin and Andy. This is very informative. I tried moving the tuner card to the PCI slot on the far end of the motherboard and leaving the video card (a GeForce 210, I think I forgot to mention) as the only other card plugged in. This however did not noticeably reduce the rate of errors. </div><div><br></div><div>Devin, you seem to be suggesting that the "glitches" I'm seeing watching TV through mythtv are not necessarily the same as the unc/ber that azap is reporting. That could also explain the difference between Linux and Windows viewing. I should mention that I can play HD television in mythtv from a firewire connection to my cable box without the glitches. But just to double-check if the application is a problem, could you guys suggest another application to view the video stream? I tried "mplayer -cache 8192 /dev/dvb/frontend0", but it does not play the video. I get the following message:</div><div><div style="text-indent: 0in !important; "><div style="text-indent: 0in !important; "><br style="text-indent: 0in !important; "></div><div style="text-indent: 0in !important; "><i>MPlayer UNKNOWN-4.4.1 (C) 2000-2009 MPlayer Team</i></div><div style="text-indent: 0in !important; "><i><br style="text-indent: 0in !important; "></i></div><div style="text-indent: 0in !important; "><i>Playing /dev/dvb/adapter0/frontend0.</i></div><div style="text-indent: 0in !important; "><i>Cache fill: 0.00% (0 bytes) </i></div><div style="text-indent: 0in !important; "><i><br style="text-indent: 0in !important; "></i></div><div style="text-indent: 0in !important; "><i><br style="text-indent: 0in !important; "></i></div><div style="text-indent: 0in !important; "><i>Exiting... (End of file)</i></div></div></div><div><br></div><div>Also, is there a way to determine if the cx18 driver is dropping packets? </div><div><br></div><div><div>Best, </div><div>Kyle</div></div><div><br></div> <br /><hr />Hotmail: Trusted email with Microsoft’s powerful SPAM protection. <a href='http://clk.atdmt.com/GBL/go/201469226/direct/01/' target='_new'>Sign up now.</a></body>
</html>