Mailing List Archive

hvr-1600, frame CRC mismatch - incomplete frame
I'm using the latest version of the cx18 drivers available from the linuxtv.org mercurial repository, which, as I understand, includes the latest performance tweaks for the Hauppage HVR-1600 by Devin Heitmueller. Unfortunately, I'm still getting occasional (~every 30 seconds) glitches in the video (watching with MythTV 0.22, Karmic x64), accompanied by an audible buzz, and the following error message in the mythfrontend.log:

2010-02-11 20:11:25.510 [ac3 @ 0x7fa2a884c820]frame CRC mismatch
2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]incomplete frame
2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]invalid frame size

The card is capable of tuning the same channel with no apparent errors in Windows XP.

Please let me know if I can provide any other information to help troubleshoot this problem.

Thanks in advance for any help you can offer.

Best,
Kyle

_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Fri, Feb 12, 2010 at 3:15 PM, Kyle Lil <kpl388@msn.com> wrote:
> I'm using the latest version of the cx18 drivers available from the
> linuxtv.org mercurial repository, which, as I understand, includes the
> latest performance tweaks for the Hauppage HVR-1600 by Devin Heitmueller.
> Unfortunately, I'm still getting occasional (~every 30 seconds) glitches in
> the video (watching with MythTV 0.22, Karmic x64), accompanied by an audible
> buzz, and the following error message in the mythfrontend.log:
>
> 2010-02-11 20:11:25.510 [ac3 @ 0x7fa2a884c820]frame CRC mismatch
> 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]incomplete frame
> 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]invalid frame size
>
> The card is capable of tuning the same channel with no apparent errors in
> Windows XP.
>
> Please let me know if I can provide any other information to help
> troubleshoot this problem.

I would suggest using azap to tune to the target channel, and then
watch the BER/UNC counts when the errors appear. That will give us
some idea whether the problem is with the frontend, or whether it's
with the bridge.

Also, do you see the issue with *all* channels? Or just particular
channels? And what is the SNR on the channels in question that show
the problem?

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
Thanks, Devin. Below is the output of azap. I'm assuming that the errors are occurring at the same time the video/audio glitches would be. I think it is slightly worse on some channels than on others (but not drastically). The example below is from one of the worse channels.

using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 799789900 Hz
video pid 0x0000, audio pid 0x0000
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 1f | signal 013e | snr 013e | ber 000019a7 | unc 000019a7 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000267 | unc 00000267 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000264 | unc 00000264 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

> Date: Fri, 12 Feb 2010 15:24:54 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Fri, Feb 12, 2010 at 3:15 PM, Kyle Lil <kpl388@msn.com> wrote:
> > I'm using the latest version of the cx18 drivers available from the
> > linuxtv.org mercurial repository, which, as I understand, includes the
> > latest performance tweaks for the Hauppage HVR-1600 by Devin Heitmueller.
> > Unfortunately, I'm still getting occasional (~every 30 seconds) glitches in
> > the video (watching with MythTV 0.22, Karmic x64), accompanied by an audible
> > buzz, and the following error message in the mythfrontend.log:
> >
> > 2010-02-11 20:11:25.510 [ac3 @ 0x7fa2a884c820]frame CRC mismatch
> > 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]incomplete frame
> > 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]invalid frame size
> >
> > The card is capable of tuning the same channel with no apparent errors in
> > Windows XP.
> >
> > Please let me know if I can provide any other information to help
> > troubleshoot this problem.
>
> I would suggest using azap to tune to the target channel, and then
> watch the BER/UNC counts when the errors appear. That will give us
> some idea whether the problem is with the frontend, or whether it's
> with the bridge.
>
> Also, do you see the issue with *all* channels? Or just particular
> channels? And what is the SNR on the channels in question that show
> the problem?
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Fri, Feb 12, 2010 at 4:26 PM, Kyle Lil <kpl388@msn.com> wrote:
> Thanks, Devin. Below is the output of azap. I'm assuming that the errors are
> occurring at the same time the video/audio glitches would be. I think it is
> slightly worse on some channels than on others (but not drastically). The
> example below is from one of the worse channels.

Yeah, it looks like you do occasionally get a BER/UNC error (despite
the SNR appearing to be stable). I wonder what is up with that.

I'll have to see if I can find some cycles to see if I can reproduce
the issue here.

Just to be clear, we're talking about ClearQAM right? (and not OTA ATSC)

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
That's correct. The card is connected to a ClearQAM cable source.

The cable is split once between the wall and the tuner card. There is about 15ft of cable to the wall and I live on the 4th floor. I wouldn't have guessed that signal strength would be my problem, as it seems to work OK in Windows or if I plug the cable into the QAM tuner on my TV. Does 0145 seem like a reasonable number for signal strength or SNR? I'm not sure how to translate that into % or dB...


> Date: Fri, 12 Feb 2010 16:44:25 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Fri, Feb 12, 2010 at 4:26 PM, Kyle Lil <kpl388@msn.com> wrote:
> > Thanks, Devin. Below is the output of azap. I'm assuming that the errors are
> > occurring at the same time the video/audio glitches would be. I think it is
> > slightly worse on some channels than on others (but not drastically). The
> > example below is from one of the worse channels.
>
> Yeah, it looks like you do occasionally get a BER/UNC error (despite
> the SNR appearing to be stable). I wonder what is up with that.
>
> I'll have to see if I can find some cycles to see if I can reproduce
> the issue here.
>
> Just to be clear, we're talking about ClearQAM right? (and not OTA ATSC)
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Fri, Feb 12, 2010 at 5:19 PM, Kyle Lil <kpl388@msn.com> wrote:
> That's correct. The card is connected to a ClearQAM cable source.
>
> The cable is split once between the wall and the tuner card. There is about
> 15ft of cable to the wall and I live on the 4th floor. I wouldn't have
> guessed that signal strength would be my problem, as it seems to work OK in
> Windows or if I plug the cable into the QAM tuner on my TV. Does 0145 seem
> like a reasonable number for signal strength or SNR? I'm not sure how to
> translate that into % or dB...

The SNR field is expressed in 0.1dB increments. Hence 0x0145
translates to 32.5 dB, which is pretty reasonable. Also, I don't see
any sign of the SNR changing at the time of the UNC/BER condition.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
OK, thanks. I very much appreciate your help with this.

I'm not sure if it's relevant, but my MB is an ASUS P5Q PRO, with a Quad 2.5GHz, and 6GB of RAM.


> Date: Fri, 12 Feb 2010 17:23:16 -0500
> From: dheitmueller@kernellabs.com
> To: ivtv-users@ivtvdriver.org
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Fri, Feb 12, 2010 at 5:19 PM, Kyle Lil <kpl388@msn.com> wrote:
> > That's correct. The card is connected to a ClearQAM cable source.
> >
> > The cable is split once between the wall and the tuner card. There is about
> > 15ft of cable to the wall and I live on the 4th floor. I wouldn't have
> > guessed that signal strength would be my problem, as it seems to work OK in
> > Windows or if I plug the cable into the QAM tuner on my TV. Does 0145 seem
> > like a reasonable number for signal strength or SNR? I'm not sure how to
> > translate that into % or dB...
>
> The SNR field is expressed in 0.1dB increments. Hence 0x0145
> translates to 32.5 dB, which is pretty reasonable. Also, I don't see
> any sign of the SNR changing at the time of the UNC/BER condition.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Fri, 2010-02-12 at 16:26 -0500, Kyle Lil wrote:
> Thanks, Devin. Below is the output of azap. I'm assuming that the
> errors are occurring at the same time the video/audio glitches would
> be. I think it is slightly worse on some channels than on others (but
> not drastically). The example below is from one of the worse
> channels.
>
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 799789900 Hz
> video pid 0x0000, audio pid 0x0000
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 013e | snr 013e | ber 000019a7 | unc 000019a7 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000267 | unc 00000267 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000264 | unc 00000264 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK


This looks like EMI of some sort to me. (Either that or some tracking
loop in the digital tuner or demod losing lock - but then SNR would
likely dip).

EMI might be coming from inside the PC. Does your computer under linux
happen to write to disk every 30 seconds or so?


Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
i've noticed this lately as well, after the initial signal quality
updates a couple of months back everything worked great for a while, but
in the last month or so i'm seeing some corruption errors as well. same
card, same machine, same signal theoretically. it seems to affect all
channels but it's still much better than before the signal quality
updates.

fyi,

Devin Heitmueller <dheitmueller@kernellabs.com> writes:

> On Fri, Feb 12, 2010 at 3:15 PM, Kyle Lil <kpl388@msn.com> wrote:
>> I'm using the latest version of the cx18 drivers available from the
>> linuxtv.org mercurial repository, which, as I understand, includes the
>> latest performance tweaks for the Hauppage HVR-1600 by Devin Heitmueller.
>> Unfortunately, I'm still getting occasional (~every 30 seconds) glitches in
>> the video (watching with MythTV 0.22, Karmic x64), accompanied by an audible
>> buzz, and the following error message in the mythfrontend.log:
>>
>> 2010-02-11 20:11:25.510 [ac3 @ 0x7fa2a884c820]frame CRC mismatch
>> 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]incomplete frame
>> 2010-02-11 20:11:25.543 [ac3 @ 0x7fa2a884c820]invalid frame size
>>
>> The card is capable of tuning the same channel with no apparent errors in
>> Windows XP.
>>
>> Please let me know if I can provide any other information to help
>> troubleshoot this problem.
>
> I would suggest using azap to tune to the target channel, and then
> watch the BER/UNC counts when the errors appear. That will give us
> some idea whether the problem is with the frontend, or whether it's
> with the bridge.
>
> Also, do you see the issue with *all* channels? Or just particular
> channels? And what is the SNR on the channels in question that show
> the problem?
>
> Devin

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
Daniel Flesner wrote:
> i've noticed this lately as well, after the initial signal quality
> updates a couple of months back everything worked great for a while, but
> in the last month or so i'm seeing some corruption errors as well. same
> card, same machine, same signal theoretically. it seems to affect all
> channels but it's still much better than before the signal quality
> updates.
>
I did the signal quality updates a few months back also, and went from
unusable to pretty good. I never got around to actually using it,
because it requires extra channel fudging, and I'm waiting until after
the mythtv-0.22 upgrade to start working on that stuff.

But that also means that mythtv doesn't yet know about the QAM/ATSC side
of my tuner cards, so I can check out azap results and see how they
compare with my earlier memories - see if I'm getting noticeable
degradation too. I never did get a good signal for the local access
channels. There's some stuff I can do on the coax feed that I haven't
gotten around to, yet. I clearly won't, for the value of a comparison,
but it will be interesting to see what it can buy me, later.

Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Fri, 12 Feb 2010 20:52:28 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Fri, 2010-02-12 at 16:26 -0500, Kyle Lil wrote:
> > Thanks, Devin. Below is the output of azap. I'm assuming that the
> > errors are occurring at the same time the video/audio glitches would
> > be. I think it is slightly worse on some channels than on others (but
> > not drastically). The example below is from one of the worse
> > channels.
> >
> > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> > tuning to 799789900 Hz
> > video pid 0x0000, audio pid 0x0000
> > status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> > status 1f | signal 013e | snr 013e | ber 000019a7 | unc 000019a7 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000267 | unc 00000267 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000264 | unc 00000264 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0146 | snr 0146 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> > status 1f | signal 0145 | snr 0145 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>
>
> This looks like EMI of some sort to me. (Either that or some tracking
> loop in the digital tuner or demod losing lock - but then SNR would
> likely dip).
>
> EMI might be coming from inside the PC. Does your computer under linux
> happen to write to disk every 30 seconds or so?
>
>
> Regards,
> Andy
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

The hard drive is being accessed pretty frequently (~1/second) when watching tv with mythtv, much more often than the errors are appearing. So, the hard drive cannot reliably produce the errors. Interestingly, I think the errors seem to occur slightly more often when watching tv with myth than when just monitoring the signal with azap. Would azap catch all errors or does it just sparsely sample the signal?
The optical drive is not spinning up and the graphics card is fanless. The only other significant EMI sources inside the computer that I can think of are the case fan, cpu fan, and maybe the power supply. I can play around with different ground configurations to see if that helps.





_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, 2010-02-13 at 12:18 -0500, Dale Pontius wrote:
> Daniel Flesner wrote:
> > i've noticed this lately as well, after the initial signal quality
> > updates a couple of months back everything worked great for a while, but
> > in the last month or so i'm seeing some corruption errors as well. same
> > card, same machine, same signal theoretically. it seems to affect all
> > channels but it's still much better than before the signal quality
> > updates.
> >
> I did the signal quality updates a few months back also, and went from
> unusable to pretty good. I never got around to actually using it,
> because it requires extra channel fudging, and I'm waiting until after
> the mythtv-0.22 upgrade to start working on that stuff.
>
> But that also means that mythtv doesn't yet know about the QAM/ATSC side
> of my tuner cards,

Hmm. I've been using MythTV with my HVR-1600's since I first got one a
few years ago. You just set it up as two separate cards: an MPEG
Encoder PVR-xxx like card and a DVB adapter.

This version of MythTV works for me:

$ mythfrontend --version
Please include all output in bug reports.
MythTV Version : 0.21-21.fc10
MythTV Branch : branches/release-0-21-fixes
Library API : 0.21.20080304-1
Network Protocol : 40
Options compiled in:
linux release using_oss using_alsa using_pulse using_arts using_jack
using_backend using_dbox2 using_dvb using_firewire using_frontend
using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc
using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr
using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl
using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3
using_live


The only problem I noticed is that the digital cahnnel scan can bomb-out
near the end. Apparently mythtv-setup tries to tune to a freq higher
than the demodulator can support and then mythtv-setup crashes when the
error code comes back from the cx18 driver. The channel scan
information up to that point is still saved however.

Or maybe I misunderstood what you were saying.

Regards,
Andy

> so I can check out azap results and see how they
> compare with my earlier memories - see if I'm getting noticeable
> degradation too. I never did get a good signal for the local access
> channels. There's some stuff I can do on the coax feed that I haven't
> gotten around to, yet. I clearly won't, for the value of a comparison,
> but it will be interesting to see what it can buy me, later.
>
> Dale Pontius
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, Feb 13, 2010 at 1:35 PM, Kyle Lil <kpl388@msn.com> wrote:
> The hard drive is being accessed pretty frequently (~1/second) when watching
> tv with mythtv, much more often than the errors are appearing. So, the hard
> drive cannot reliably produce the errors. Interestingly, I think the errors
> seem to occur slightly more often when watching tv with myth than when just
> monitoring the signal with azap. Would azap catch all errors or does it just
> sparsely sample the signal?
> The optical drive is not spinning up and the graphics card is fanless. The
> only other significant EMI sources inside the computer that I can think of
> are the case fan, cpu fan, and maybe the power supply. I can play around
> with different ground configurations to see if that helps.

Kyle,

Just to be clear, the BER/UNC counters count the number of errors
*only* between the tuner and demodulator. These are errors where the
Reed-Solomon error correction built into the signal could not
compensate (essentially errors in the analog signal transmission).
I'm pointing this out to make clear that those counters do not track
any *other* possible class of problem, such as packets being lost in
the cx18 driver, the application's failure to read the packets from
the driver fast enough (resulting in the packets being dropped by the
driver), or problems writing the MPEG frames to the hard disk, etc.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
> > This looks like EMI of some sort to me. (Either that or some
> tracking
> > loop in the digital tuner or demod losing lock - but then SNR would
> > likely dip).
> >
> > EMI might be coming from inside the PC. Does your computer under
> linux
> > happen to write to disk every 30 seconds or so?


> The hard drive is being accessed pretty frequently (~1/second) when
> watching tv with mythtv, much more often than the errors are
> appearing. So, the hard drive cannot reliably produce the errors.
> Interestingly, I think the errors seem to occur slightly more often
> when watching tv with myth than when just monitoring the signal with
> azap. Would azap catch all errors or does it just sparsely sample the
> signal?

The unc errors are accumulated in hardware counters in the CX24227
digital demodulator and then (unfortunately) cleared by the CX24227
hardware after an application like azap asks for the statistics to be
read out. But if you know you only have one app reading the stats, and
I'm pretty sure MythTV doesn't read them regularly, then you should be
getting realistic reporting.


BTW: the s5h1409 driver for the CX24227 really only reports
uncorrectable block count and SNR. You can ignore the Signal and BER
values as they are just duplicates of the other values.



> The optical drive is not spinning up and the graphics card is fanless.
> The only other significant EMI sources inside the computer that I can
> think of are the case fan, cpu fan, and maybe the power supply. I can
> play around with different ground configurations to see if that
> helps.

I would try moving the card to the slot farthest from where it is now or
simply just away from other cards. The MXL5005s digital tuner is inside
a little metal shield, but, IIRC the board traces over to the CX24227
and the CX24227 are not shielded.


BTW

I'm looking at the output of femon (since mythbackend has the adapter
open) for my HVR-1600. With ATSC 8-VSB, I get an occasional error on a
weak station, but not on the strong ones (except one or two lines after
mythbackend changes the RF channel).

That doesn't tell us too much about QAM demodulation though.

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
Andy Walls wrote:
> On Sat, 2010-02-13 at 12:18 -0500, Dale Pontius wrote:
>> Daniel Flesner wrote:
>>> i've noticed this lately as well, after the initial signal quality
>>> updates a couple of months back everything worked great for a while, but
>>> in the last month or so i'm seeing some corruption errors as well. same
>>> card, same machine, same signal theoretically. it seems to affect all
>>> channels but it's still much better than before the signal quality
>>> updates.
>>>
>> I did the signal quality updates a few months back also, and went from
>> unusable to pretty good. I never got around to actually using it,
>> because it requires extra channel fudging, and I'm waiting until after
>> the mythtv-0.22 upgrade to start working on that stuff.
>>
>> But that also means that mythtv doesn't yet know about the QAM/ATSC side
>> of my tuner cards,
>
> Hmm. I've been using MythTV with my HVR-1600's since I first got one a
> few years ago. You just set it up as two separate cards: an MPEG
> Encoder PVR-xxx like card and a DVB adapter.
>
> This version of MythTV works for me:
>
> $ mythfrontend --version
> Please include all output in bug reports.
> MythTV Version : 0.21-21.fc10
> MythTV Branch : branches/release-0-21-fixes
> Library API : 0.21.20080304-1
> Network Protocol : 40
> Options compiled in:
> linux release using_oss using_alsa using_pulse using_arts using_jack
> using_backend using_dbox2 using_dvb using_firewire using_frontend
> using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc
> using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr
> using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl
> using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3
> using_live
>
>
> The only problem I noticed is that the digital cahnnel scan can bomb-out
> near the end. Apparently mythtv-setup tries to tune to a freq higher
> than the demodulator can support and then mythtv-setup crashes when the
> error code comes back from the cx18 driver. The channel scan
> information up to that point is still saved however.
>
> Or maybe I misunderstood what you were saying.
>
Sorry, I guess I wasn't clear. I haven't yet bothered to tell myth
about the HD side of my cards. Since it's ClearQAM, it isn't really
covered by any lineup I could grab from SchedulesDirect, and that means
I have to learn about channel editing. Since my time for this stuff is
rather limited, I'm just waiting until after I've upgraded to 0.22, then
I'll dig back into it.

In the meantime, I went back and ran azap against what I find, and see
that my SNR is as good as it was back on Nov 29, when I put the signal
improvement drivers on - if not better. I still don't have a very good
signal for the 2 public access channels - but I didn't then, either. As
I said, there are still a few tricks I can pull for signal improvement,
but haven't taken the time to do, since everything else is working
pretty well.

Dale Pontius

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, 2010-02-13 at 14:32 -0500, Devin Heitmueller wrote:
> On Sat, Feb 13, 2010 at 1:35 PM, Kyle Lil <kpl388@msn.com> wrote:
> > The hard drive is being accessed pretty frequently (~1/second) when watching
> > tv with mythtv, much more often than the errors are appearing. So, the hard
> > drive cannot reliably produce the errors. Interestingly, I think the errors
> > seem to occur slightly more often when watching tv with myth than when just
> > monitoring the signal with azap. Would azap catch all errors or does it just
> > sparsely sample the signal?
> > The optical drive is not spinning up and the graphics card is fanless. The
> > only other significant EMI sources inside the computer that I can think of
> > are the case fan, cpu fan, and maybe the power supply. I can play around
> > with different ground configurations to see if that helps.
>
> Kyle,
>
> Just to be clear, the BER/UNC counters count the number of errors
> *only* between the tuner and demodulator. These are errors where the
> Reed-Solomon error correction built into the signal could not
> compensate (essentially errors in the analog signal transmission).
> I'm pointing this out to make clear that those counters do not track
> any *other* possible class of problem,

Devin,

Right. My statement about EMI was that signals inside the computer are
affecting the IF signal on the card.

(Sometime back on a list that I monitor, I recall someone with a disk
controller right next to their TV capture card causing problems. Moving
the TV card away from the disk controller card fixed the issue.)

Since SNR wasn't really changing for Kyle, my guess was the errors come
from strong "narrowband" and/or "burst" noise superimposed onto the IF
from within his computer. Since the operation of the computer internals
could easily behave differently between Windows and Linux, this seemed
plausible to explain different results between Linux to Windows.


The SNR reported for QAM is just a conversion from an averaged quantity
being reported by the chip. I suppose the averaging interval could be
hiding actual error bursts coming down the cable, so we never see SNR
dip. However that would not explain why he didn't notice any video
defects under Windows (assuming the Windows rendering app and linux
rendering app handle errors in the same way).



> such as packets being lost in
> the cx18 driver, the application's failure to read the packets from
> the driver fast enough (resulting in the packets being dropped by the
> driver), or problems writing the MPEG frames to the hard disk, etc.

My suggestion was more about disk activity causing EMI internal to the
PC case. I had in mind perhaps a disk controller card next to the
HVR-1600.

Regards,
Andy

> Devin



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, 2010-02-13 at 15:08 -0500, Dale Pontius wrote:
> Sorry, I guess I wasn't clear. I haven't yet bothered to tell myth
> about the HD side of my cards. Since it's ClearQAM, it isn't really
> covered by any lineup I could grab from SchedulesDirect, and that means
> I have to learn about channel editing. Since my time for this stuff is
> rather limited, I'm just waiting until after I've upgraded to 0.22, then
> I'll dig back into it.

Ah, OK. For ATSC OTA, the channel information comes in the digital
signal. Also about a day's worth of programming schedule comes over the
air as well, since I have MythTV set to scan for the EIT.

I don't know what the deal is for Cable.

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
Andy Walls wrote:
> On Sat, 2010-02-13 at 15:08 -0500, Dale Pontius wrote:
>> Sorry, I guess I wasn't clear. I haven't yet bothered to tell myth
>> about the HD side of my cards. Since it's ClearQAM, it isn't really
>> covered by any lineup I could grab from SchedulesDirect, and that means
>> I have to learn about channel editing. Since my time for this stuff is
>> rather limited, I'm just waiting until after I've upgraded to 0.22, then
>> I'll dig back into it.
>
> Ah, OK. For ATSC OTA, the channel information comes in the digital
> signal. Also about a day's worth of programming schedule comes over the
> air as well, since I have MythTV set to scan for the EIT.
>
> I don't know what the deal is for Cable.
>
Nada. Zip. I'm completely on my own. There are resources, and what I
get in ClearQAM is on SchedulesDirect OTA. But they have to be married
together by hand. There are resources for doing it, but none of the
process looks simple to me, and if I'm going to have to take the time
learning something, most notably getting mythweb running, (which it
doesn't for me, out of the box) I'm going to wait for 0.22.

Dale

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Sat, 13 Feb 2010 15:54:23 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Sat, 2010-02-13 at 14:32 -0500, Devin Heitmueller wrote:
> > On Sat, Feb 13, 2010 at 1:35 PM, Kyle Lil <kpl388@msn.com> wrote:
> > > The hard drive is being accessed pretty frequently (~1/second) when watching
> > > tv with mythtv, much more often than the errors are appearing. So, the hard
> > > drive cannot reliably produce the errors. Interestingly, I think the errors
> > > seem to occur slightly more often when watching tv with myth than when just
> > > monitoring the signal with azap. Would azap catch all errors or does it just
> > > sparsely sample the signal?
> > > The optical drive is not spinning up and the graphics card is fanless. The
> > > only other significant EMI sources inside the computer that I can think of
> > > are the case fan, cpu fan, and maybe the power supply. I can play around
> > > with different ground configurations to see if that helps.
> >
> > Kyle,
> >
> > Just to be clear, the BER/UNC counters count the number of errors
> > *only* between the tuner and demodulator. These are errors where the
> > Reed-Solomon error correction built into the signal could not
> > compensate (essentially errors in the analog signal transmission).
> > I'm pointing this out to make clear that those counters do not track
> > any *other* possible class of problem,
>
> Devin,
>
> Right. My statement about EMI was that signals inside the computer are
> affecting the IF signal on the card.
>
> (Sometime back on a list that I monitor, I recall someone with a disk
> controller right next to their TV capture card causing problems. Moving
> the TV card away from the disk controller card fixed the issue.)
>
> Since SNR wasn't really changing for Kyle, my guess was the errors come
> from strong "narrowband" and/or "burst" noise superimposed onto the IF
> from within his computer. Since the operation of the computer internals
> could easily behave differently between Windows and Linux, this seemed
> plausible to explain different results between Linux to Windows.
>
>
> The SNR reported for QAM is just a conversion from an averaged quantity
> being reported by the chip. I suppose the averaging interval could be
> hiding actual error bursts coming down the cable, so we never see SNR
> dip. However that would not explain why he didn't notice any video
> defects under Windows (assuming the Windows rendering app and linux
> rendering app handle errors in the same way).
>
>
>
> > such as packets being lost in
> > the cx18 driver, the application's failure to read the packets from
> > the driver fast enough (resulting in the packets being dropped by the
> > driver), or problems writing the MPEG frames to the hard disk, etc.
>
> My suggestion was more about disk activity causing EMI internal to the
> PC case. I had in mind perhaps a disk controller card next to the
> HVR-1600.
>
> Regards,
> Andy
>
> > Devin
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

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.
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:MPlayer UNKNOWN-4.4.1 (C) 2000-2009 MPlayer TeamPlaying /dev/dvb/adapter0/frontend0.Cache fill: 0.00% (0 bytes) Exiting... (End of file)
Also, is there a way to determine if the cx18 driver is dropping packets?
Best, Kyle

_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, Feb 13, 2010 at 7:33 PM, Kyle Lil <kpl388@msn.com> wrote:
> 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.

> 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'm not ruling out the possibility of a problem with the demod, but
just trying to make clear that there could be other explanations, and
the UNC counter is not the only indicator that there could be a
problem. For example, the demod and tuner could be working fine, but
if further down the pipeline the cx18 driver drops half the packets
then the UNC would be perfect but you obviously couldn't expect the
video to play back properly.

Also, the different applications vary drastically in terms of how they
well they compensate for errors. You could have a well written MPEG
codec which handles a high threshold of errors without you noticing,
and you could have worse codecs that reset the stream on even the
slightest of errors, which would be highly noticeable.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, 2010-02-13 at 19:33 -0500, Kyle Lil wrote:

> 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.
>
>
> 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:
>

You need to make a channels.conf file with scan (or scandvb or dvbscan
or whatever your distro calls it) and put it under
~/.mplayer/channels.conf.

Then

$ mplayer dvb://WFOO-DT -cache 8192

should work. You make need to do something like

$ mplayer dvb://WFOO-DT -cache 8192 -vf scale=960:540

for example to set the software scaler in mplayer to scale 1920x1080
content down to fit on the screen.


>
> Also, is there a way to determine if the cx18 driver is dropping
> packets?

As root

# echo 15 > /sys/modules/cx18/parameters/debug

and then look in /var/log/messages or the dmesg command output or some
other log for "Possibly falling behind", "Fell behind", or "must have
fallen out of rotation". The first message type indicates you may have
missed shuffling data. The other two indicate that you have. If you
get these messages, it means your system is having trouble keeping up
and serviceing interrupts from the CX23418.

This all of course has nothing to do with SNR and unc, but could be a
cause of TS corruption obviously.

Regards,
Andy

> Best,
> Kyle




_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
> From: awalls@radix.net> To: ivtv-users@ivtvdriver.org
> Date: Sat, 13 Feb 2010 20:20:21 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Sat, 2010-02-13 at 19:33 -0500, Kyle Lil wrote:
>
> > 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.
> >
> >
> > 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:
> >
>
> You need to make a channels.conf file with scan (or scandvb or dvbscan
> or whatever your distro calls it) and put it under
> ~/.mplayer/channels.conf.
>
> Then
>
> $ mplayer dvb://WFOO-DT -cache 8192
>
> should work. You make need to do something like
>
> $ mplayer dvb://WFOO-DT -cache 8192 -vf scale=960:540
>
> for example to set the software scaler in mplayer to scale 1920x1080
> content down to fit on the screen.
>
>
> >
> > Also, is there a way to determine if the cx18 driver is dropping
> > packets?
>
> As root
>
> # echo 15 > /sys/modules/cx18/parameters/debug
>
> and then look in /var/log/messages or the dmesg command output or some
> other log for "Possibly falling behind", "Fell behind", or "must have
> fallen out of rotation". The first message type indicates you may have
> missed shuffling data. The other two indicate that you have. If you
> get these messages, it means your system is having trouble keeping up
> and serviceing interrupts from the CX23418.
>
> This all of course has nothing to do with SNR and unc, but could be a
> cause of TS corruption obviously.
>
> Regards,
> Andy
>
> > Best,
> > Kyle
>
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

OK, Great. So, enabling the debug messages as you described results in a ton of these messages:[ 1312.000257] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1312.500011] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1313.000017] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1315.080014] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1315.310061] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1316.330025] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs[ 1316.870079] cx18-0: warning: failed to be awakened upon RPU acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecsand an occasional message like this:[ 1311.480015] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 10 msecs for RPU acknowledgementExecuting mplayer as you described now attempts to fill the cache and play video, but is taking forever to fill the cache. To get 0.1% (8192 bytes) takes 13 seconds. It hasn't yet completely filled the cache, but it has given a couple of error messages saying "dvb_streaming_read, attempt N. 6 failed with errno 0 when reading x bytes". It is now at about 10%



_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Sat, 2010-02-13 at 21:20 -0500, Kyle Lil wrote:
> > From: awalls@radix.net


> OK, Great. So, enabling the debug messages as you described results in
> a ton of these messages:
>
>
> [ 1312.000257] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1312.500011] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1313.000017] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1315.080014] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1315.310061] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1316.330025] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> [ 1316.870079] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs

Those aren't so bad. These happen when we give a buffer bad to the
CX23418 and it doesn't respond *right away*. The cx18-0-out/n work
handler will go to sleep waiting for a wake-up from the CX23418 via an
IRQ. Usually the ACK IRQ happens well within 10 msecs, but the Linux
scheduler doesn't get around to waking up the cx18-0-out/n work handler,
so you get this message instead when a timer ends up waking it up.

Short story: no big deal as far as the CX23418 is concerned.


On the other hand, your system load or interrupt handling latency may be
high.


> and an occasional message like this:
>
>
> [ 1311.480015] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out
> waiting 10 msecs for RPU acknowledgement

This is an instance when the CX23418 firmware actually didn't ACK us
within 10 msecs of us sending an empty buffer back. This means the
firmware was very busy at the moment, or was ignoring us because it
didn't make sense for us to be giving it a buffer at that time (i.e. we
were stopping the streaming). This isn't a big deal unless it happens
often.


> Executing mplayer as you described now attempts to fill the cache and
> play video, but is taking forever to fill the cache. To get 0.1% (8192
> bytes) takes 13 seconds. It hasn't yet completely filled the cache,
> but it has given a couple of error messages saying
> "dvb_streaming_read, attempt N. 6 failed with errno 0 when reading x
> bytes". It is now at about 10%

That's certainly not what should happen normally. With a good stream
(or good signal?), it should get up to 19% cache fill and start playing
within about 5 seconds.

Like so:

$ time mplayer dvb://WTTG\ DT -cache 8192
MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
43, Stepping: 1)
mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
mplayer: No such file or directory
Failed to read LIRC config file ~/.lircrc.

Playing dvb://WTTG DT.
dvb_tune Freq: 605028615
Cache fill: 19.14% (1605632 bytes)
TS file format detected.
VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)! PROGRAM N. 0
VIDEO: MPEG2 1280x720 (aspect 3) 59.940 fps 19000.0 kbps (2375.0
kbyte/s)
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
==========================================================================
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 448.0 kbit/29.17% (ratio: 56000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1280x720 => 1280x720 Planar YV12
A:49184.3 V:49184.7 A-V: -0.335 ct: -0.065 40/ 40 126% 6% 5.1% 4 0
14%
Exiting... (Quit)

real 0m4.303s
user 0m0.604s
sys 0m0.148s



With a poor stream due to weak signal, I get something like this with
ATSC:

$ time mplayer dvb://WJLA-HD -cache 8192
MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
43, Stepping: 1)
mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
mplayer: No such file or directory
Failed to read LIRC config file ~/.lircrc.

Playing dvb://WJLA-HD.
dvb_tune Freq: 177028615
Cache fill: 8.79% (737280 bytes) dvb_streaming_read, attempt N. 6
failed with errno 0 when reading 844 bytes
Cache fill: 8.79% (737280 bytes) dvb_streaming_read, attempt N. 5
failed with errno 0 when reading 844 bytes
Cache fill: 19.34% (1622016 bytes)
TS file format detected.
VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)! PROGRAM N. 0
VIDEO: MPEG2 1280x720 (aspect 3) 59.940 fps 17782.8 kbps (2222.8
kbyte/s)
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
==========================================================================
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
a52: CRC check failed!
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1280x720 => 1280x720 Planar YV12
[mpeg2video @ 0xac4480]skipped MB in I frame at 65 5
[mpeg2video @ 0xac4480]Warning MVs not available
[mpeg2video @ 0xac4480]concealing 1984 DC, 1984 AC, 1984 MV errors
a52: CRC check failed! 1481.898 ct: 0.000 1/ 1 ??% ??% ??,?% 0 0
1%
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
[mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
a52: CRC check failed! 2.479 ct: 0.002 2/ 2 ??% ??% ??,?% 0 0
0%
a52: error at resampling
a52: CRC check failed!
[mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
a52: CRC check failed! 2.496 ct: 0.003 3/ 3 ??% ??% ??,?% 0 0
0%
a52: error at resampling
a52: CRC check failed!
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
[mpeg2video @ 0xac4480]ac-tex damaged at 62 28
[mpeg2video @ 0xac4480]Warning MVs not available
[mpeg2video @ 0xac4480]concealing 1352 DC, 1352 AC, 1352 MV errors
a52: CRC check failed! 3.353 ct: 0.005 4/ 4 ??% ??% ??,?% 0 0
0%
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed! 3.537 ct: 0.007 5/ 5 ??% ??% ??,?% 0 0
0%
a52: error at resampling
a52: CRC check failed!
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed! 3.844 ct: 0.008 6/ 6 ??% ??% ??,?% 1 0
0%
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
a52: CRC check failed!
a52: error at resampling
A:91484.4 V:91480.1 A-V: 4.286 ct: 0.010 7/ 7 ??% ??% ??,?% 2 0
0%
Exiting... (Quit)

real 0m8.538s
user 0m0.318s
sys 0m0.163s




So mplayer is not very robust when dealing with streams with errors. It
is very good at indicating to you that you have a stream with errors
apparently.

Windows might be able to better render smoothly through the errors.
BTW, what does the Windows utility form Hauppauge show for signal
strength? (I haven't used it, I just heard that Hauppauge provides one
with its osftware.)



The only other thing I can think of is that the cable signal could be
slightly overamplified so it is overdriving the front end of the tuner
and introducing these errors.

You might want to put an attenuator in line to reduce the RF level a bit
and see if that helps. If you can't find an in-line attenuator at a
local electronics store, here's how to build a Bridged-T attenuator from
resistors yourself:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg08735.html

I guess you would want to try a "Gain" of about -3 dB first and then -10
dB if the problem still seems to happen.



And of course there's always the checklist here to go through:

http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality


Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
> From: awalls@radix.net
> To: ivtv-users@ivtvdriver.org
> Date: Sat, 13 Feb 2010 23:05:41 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
>
> On Sat, 2010-02-13 at 21:20 -0500, Kyle Lil wrote:
> > > From: awalls@radix.net
>
>
> > OK, Great. So, enabling the debug messages as you described results in
> > a ton of these messages:
> >
> >
> > [ 1312.000257] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1312.500011] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1313.000017] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1315.080014] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1315.310061] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1316.330025] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1316.870079] cx18-0: warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
>
> Those aren't so bad. These happen when we give a buffer bad to the
> CX23418 and it doesn't respond *right away*. The cx18-0-out/n work
> handler will go to sleep waiting for a wake-up from the CX23418 via an
> IRQ. Usually the ACK IRQ happens well within 10 msecs, but the Linux
> scheduler doesn't get around to waking up the cx18-0-out/n work handler,
> so you get this message instead when a timer ends up waking it up.
>
> Short story: no big deal as far as the CX23418 is concerned.
>
>
> On the other hand, your system load or interrupt handling latency may be
> high.
>
>
> > and an occasional message like this:
> >
> >
> > [ 1311.480015] cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out
> > waiting 10 msecs for RPU acknowledgement
>
> This is an instance when the CX23418 firmware actually didn't ACK us
> within 10 msecs of us sending an empty buffer back. This means the
> firmware was very busy at the moment, or was ignoring us because it
> didn't make sense for us to be giving it a buffer at that time (i.e. we
> were stopping the streaming). This isn't a big deal unless it happens
> often.
>
>
> > Executing mplayer as you described now attempts to fill the cache and
> > play video, but is taking forever to fill the cache. To get 0.1% (8192
> > bytes) takes 13 seconds. It hasn't yet completely filled the cache,
> > but it has given a couple of error messages saying
> > "dvb_streaming_read, attempt N. 6 failed with errno 0 when reading x
> > bytes". It is now at about 10%
>
> That's certainly not what should happen normally. With a good stream
> (or good signal?), it should get up to 19% cache fill and start playing
> within about 5 seconds.
>
> Like so:
>
> $ time mplayer dvb://WTTG\ DT -cache 8192
> MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
> 43, Stepping: 1)
> mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
> mplayer: No such file or directory
> Failed to read LIRC config file ~/.lircrc.
>
> Playing dvb://WTTG DT.
> dvb_tune Freq: 605028615
> Cache fill: 19.14% (1605632 bytes)
> TS file format detected.
> VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)! PROGRAM N. 0
> VIDEO: MPEG2 1280x720 (aspect 3) 59.940 fps 19000.0 kbps (2375.0
> kbyte/s)
> ==========================================================================
> Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
> VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Try appending the scale filter to your filter list,
> e.g. -vf spp,scale instead of -vf spp.
> VDecoder init failed :(
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
> ==========================================================================
> ==========================================================================
> Opening audio decoder: [liba52] AC3 decoding with liba52
> Using SSE optimized IMDCT transform
> Using MMX optimized resampler
> AUDIO: 48000 Hz, 2 ch, s16le, 448.0 kbit/29.17% (ratio: 56000->192000)
> Selected audio codec: [a52] afm: liba52 (AC3-liba52)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
> Starting playback...
> VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [xv] 1280x720 => 1280x720 Planar YV12
> A:49184.3 V:49184.7 A-V: -0.335 ct: -0.065 40/ 40 126% 6% 5.1% 4 0
> 14%
> Exiting... (Quit)
>
> real 0m4.303s
> user 0m0.604s
> sys 0m0.148s
>
>
>
> With a poor stream due to weak signal, I get something like this with
> ATSC:
>
> $ time mplayer dvb://WJLA-HD -cache 8192
> MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
> 43, Stepping: 1)
> mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
> mplayer: No such file or directory
> Failed to read LIRC config file ~/.lircrc.
>
> Playing dvb://WJLA-HD.
> dvb_tune Freq: 177028615
> Cache fill: 8.79% (737280 bytes) dvb_streaming_read, attempt N. 6
> failed with errno 0 when reading 844 bytes
> Cache fill: 8.79% (737280 bytes) dvb_streaming_read, attempt N. 5
> failed with errno 0 when reading 844 bytes
> Cache fill: 19.34% (1622016 bytes)
> TS file format detected.
> VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)! PROGRAM N. 0
> VIDEO: MPEG2 1280x720 (aspect 3) 59.940 fps 17782.8 kbps (2222.8
> kbyte/s)
> ==========================================================================
> Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
> VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Try appending the scale filter to your filter list,
> e.g. -vf spp,scale instead of -vf spp.
> VDecoder init failed :(
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
> ==========================================================================
> ==========================================================================
> Opening audio decoder: [liba52] AC3 decoding with liba52
> Using SSE optimized IMDCT transform
> a52: CRC check failed!
> Using MMX optimized resampler
> AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
> Selected audio codec: [a52] afm: liba52 (AC3-liba52)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
> Starting playback...
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [xv] 1280x720 => 1280x720 Planar YV12
> [mpeg2video @ 0xac4480]skipped MB in I frame at 65 5
> [mpeg2video @ 0xac4480]Warning MVs not available
> [mpeg2video @ 0xac4480]concealing 1984 DC, 1984 AC, 1984 MV errors
> a52: CRC check failed! 1481.898 ct: 0.000 1/ 1 ??% ??% ??,?% 0 0
> 1%
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> [mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
> a52: CRC check failed! 2.479 ct: 0.002 2/ 2 ??% ??% ??,?% 0 0
> 0%
> a52: error at resampling
> a52: CRC check failed!
> [mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
> a52: CRC check failed! 2.496 ct: 0.003 3/ 3 ??% ??% ??,?% 0 0
> 0%
> a52: error at resampling
> a52: CRC check failed!
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> [mpeg2video @ 0xac4480]ac-tex damaged at 62 28
> [mpeg2video @ 0xac4480]Warning MVs not available
> [mpeg2video @ 0xac4480]concealing 1352 DC, 1352 AC, 1352 MV errors
> a52: CRC check failed! 3.353 ct: 0.005 4/ 4 ??% ??% ??,?% 0 0
> 0%
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed! 3.537 ct: 0.007 5/ 5 ??% ??% ??,?% 0 0
> 0%
> a52: error at resampling
> a52: CRC check failed!
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed! 3.844 ct: 0.008 6/ 6 ??% ??% ??,?% 1 0
> 0%
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> a52: CRC check failed!
> a52: error at resampling
> A:91484.4 V:91480.1 A-V: 4.286 ct: 0.010 7/ 7 ??% ??% ??,?% 2 0
> 0%
> Exiting... (Quit)
>
> real 0m8.538s
> user 0m0.318s
> sys 0m0.163s
>
>
>
>
> So mplayer is not very robust when dealing with streams with errors. It
> is very good at indicating to you that you have a stream with errors
> apparently.
>
> Windows might be able to better render smoothly through the errors.
> BTW, what does the Windows utility form Hauppauge show for signal
> strength? (I haven't used it, I just heard that Hauppauge provides one
> with its osftware.)
>
>
>
> The only other thing I can think of is that the cable signal could be
> slightly overamplified so it is overdriving the front end of the tuner
> and introducing these errors.
>
> You might want to put an attenuator in line to reduce the RF level a bit
> and see if that helps. If you can't find an in-line attenuator at a
> local electronics store, here's how to build a Bridged-T attenuator from
> resistors yourself:
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg08735.html
>
> I guess you would want to try a "Gain" of about -3 dB first and then -10
> dB if the problem still seems to happen.
>
>
>
> And of course there's always the checklist here to go through:
>
> http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality
>
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


OK, so it seems like we're narrowing down the problem.
After ~25minutes of mplayer trying to fill the cache today, I get to the "TS file format detected" message. Then about 15 minutes later came the dvb_streaming_read message. It never began to show video in the 72 minutes I allowed it to try.
$time mplayer "dvb://WHDH HD" -cache 8192MPlayer UNKNOWN-4.4.1 (C) 2000-2009 MPlayer Team
Playing dvb://WHDH HD.dvb_tune Freq: 799789900Cache fill: 19.92% (1671168 bytes) TS file format detected.dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 1896 bytes
I was able to use vlc to view the stream. It also had video glitches, but with less noticeable audio buzzing accompanying them. VLC spit out the following messages around the same time as the glitches. I deleted a bunch of the libdvbpsi PMT decoder messages, b/c they are generated constantly (and I think they're related to vlc's inability to deal with subchannels). The TS discontinuity errors at the beginning occurred at approximately the same time as the glitch. The QPainter messages came in the seconds following the glitch. libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi error (PSI decoder): TS discontinuity (received 2, expected 4) for PID 0libdvbpsi error (PSI decoder): TS discontinuity (received 8, expected 7) for PID 48libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 12, expected 11) for PID 49libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 5, expected 4) for PID 50libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 4, expected 3) for PID 0libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)QPainter::begin: Paint device returned engine == 0, type: 1libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)QPainter::begin: Paint device returned engine == 0, type: 1libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)QPainter::begin: Paint device returned engine == 0, type: 1QPainter::begin: Paint device returned engine == 0, type: 1libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)

I'm not sure if this offers any more clues, but I figured I'd post it just in case.
Previously I'd had the tuner connected at the end of additional splitters and devices, but I shortened the chain in troubleshooting. I'll try attenuating the signal again to see if that helps. I hadn't consider the possibility that the cable signal might exceed the devices input limits.
Thanks again for all your ideas, Kyle


_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
Re: hvr-1600, frame CRC mismatch - incomplete frame [ In reply to ]
On Mon, 2010-02-15 at 16:22 -0500, Kyle Lil wrote:

> Previously I'd had the tuner connected at the end of additional
> splitters and devices, but I shortened the chain in troubleshooting.
> I'll try attenuating the signal again to see if that helps. I hadn't
> consider the possibility that the cable signal might exceed the
> devices input limits.

Actually, I've just verified that my antenna and preamp is overdriving
my HVR-1600 for two digital TV stations. I could verify independently
with my Sony TV, which provides SNR, signal, and Error readouts of the
same channels. For me, WJLA and WUSA over the air are *really* strong
according to the TV, but my MythTV recordings show errors. Here's the
output of femon while MythTV is showing WUSA:

status 1f | signal 011d | snr 011d | ber 000001c9 | unc 000001c9 | FE_HAS_LOCK
status 1f | signal 011d | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 0000006a | unc 0000006a | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 000007f3 | unc 000007f3 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0113 | snr 0118 | ber 00000836 | unc 00000836 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0118 | snr 0118 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 011d | snr 011d | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0122 | snr 0122 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

SNR is great, but I get errors every once in a while.

The pattern looks really similar to what you reported from azap.

My problem is subject to weather variations for me, so it doesn't happen
all the time. However, clear, cold winter nights seem to lead to the
most problems recording these station with my HVR-1600. (I could turn
down my amp, but since WETA, a really good station, is a really weak
signal for me, I probably won't.)


I think you'll just need to attenuate your cable signal before it hits
the HVR-1600.

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

1 2  View All