Poor HVR 1600 Video Quality

Poor HVR 1600 Video Quality

[Bob Lightfoot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Linux Media Community:
    I am struggling with what has changed in recent {past 6-9 months} of
kernel releases as related to the HVR-1600 Tuner Card and Analog Signal
processing.  I spent the bulk of today going through my video chain
feeding into the HVR-1600 and tried multiple sources all of which
provide good video and sound when fed into a Sanyo TV bought in the
1990s.  They all produce recordings similar to the attached file.
It almost looks like noise on the system and I am beginning to suspect
my card may be hosed on the analog side.  Just looking for any thing I
may have missed while RTFM and Google.  I'd share a 1 minute sample
capture but 30.5 mb is too large to attach to a google email and I'm not
sure where to drop a sample file for others to download and check out.
It should be noted analog video was fine, but sound was intermittent
with the kernels and drivers in use back in May.  Now the sound it rock
solid, but the video has gone noisy.

The particulars of my system are as follows:

HP Pavillion Elite M9040n - Purchased 2010 with an HVR-1600

uname -a :
> Linux mythbox.ladodomain 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov
>  6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

lspci -vvv :
> 01:00.0 Multimedia video controller: Conexant Systems, Inc. CX23418
> Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast
> Audio Decoder Subsystem: Hauppauge computer works Inc. WinTV
> HVR-1600 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+
> VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+
> 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx- Latency: 64 (500ns min, 50000ns max),
> Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region
> 0: Memory at f4000000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [44] Vital Product Data Not readable Capabilities:
> [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2-
> AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 
> NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: 
> cx18 Kernel modules: cx18

lsmod | grep cx18 :
> cx18_alsa               7420  1 cx18                  125338  59 
> cx18_alsa i2c_algo_bit            5762  1 cx18 cx2341x 19763  2 
> cx18,cx23885 v4l2_common            10670  6 
> cs5345,cx18,tuner,cx25840,cx23885,cx2341x videodev 76310  7 
> cs5345,cx18,tuner,cx25840,cx23885,cx2341x,v4l2_common dvb_core 
> 104074  3 cx18,cx23885,videobuf_dvb tveeprom 14044  2 cx18,cx23885 
> snd_pcm                85828  3 
> cx18_alsa,snd_hda_intel,snd_hda_codec snd                    71339
>  15 
> cx18_alsa,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
>
>
>
> 
Sincerely,
Bob Lightfoot

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsQR7AAoJEKqgpLIhfz3XnuAH/AuO5z4Lz2hJD+ItBztf5uUE
UEvPEvOkacQxDHJr7yMNdNd8XfHQiyahKS8brnATlUJLSllQ7L4QfyFJdL+X2o0z
0QXln/M6jdx+o86Yd284fKtWBQBPMAnpWRDH4TVMeitHsJyFgNAZgSlkSXlg+Slv
qET4vDLnmLRZ32n+bZop+2gr3KySgg/K6wepo38rreiUneF4aQdYJoslKV7PjrXE
Z87KjEp+iB2p4kTdRR4cO0bCIMtInzpdxfS5vJi33T2XHFvTqD7u3TfTDIQ31A4b
ey9gC1ahAXrFOYp2rxFYZK17733Py2MicLU+vE8tIkt62kKvfwQB3RZHwVxNFjY=
=HYnR
-----END PGP SIGNATURE-----

Re: Poor HVR 1600 Video Quality

[Devin Heitmueller]

On Sat, Nov 24, 2012 at 12:31 PM, Bob Lightfoot <boblfoot@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear Linux Media Community:
>     I am struggling with what has changed in recent {past 6-9 months} of
> kernel releases as related to the HVR-1600 Tuner Card and Analog Signal
> processing.  I spent the bulk of today going through my video chain
> feeding into the HVR-1600 and tried multiple sources all of which
> provide good video and sound when fed into a Sanyo TV bought in the
> 1990s.  They all produce recordings similar to the attached file.
> It almost looks like noise on the system and I am beginning to suspect
> my card may be hosed on the analog side.  Just looking for any thing I
> may have missed while RTFM and Google.  I'd share a 1 minute sample
> capture but 30.5 mb is too large to attach to a google email and I'm not
> sure where to drop a sample file for others to download and check out.
> It should be noted analog video was fine, but sound was intermittent
> with the kernels and drivers in use back in May.  Now the sound it rock
> solid, but the video has gone noisy.

A few questions,

Which version of the HVR-1600 do you have?  Could you provide the
exact PCI ID, vendor ID, and subsystem ID?

Can you post the 1-minute video to a website where it can be downloaded?

Are you using the coax input?  Composite?  S-video?  If you're using
the coax input, it would be good just as a test for you to try the
s-video input, as that would help rule out various problems that could
be introduced by the tuner and demodulation phases.

Are you capturing MPEG compressed video or raw?  The HVR-1600 supports both.

Are you familiar enough with compiling kernels that you could bisect
this down to a specific commit which introduces the problem?

What application(s) are you testing with?

Devin

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

Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24

[Bob Lightfoot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Devin :
     Let me see if I can answer some of your questions.

1. lspci -nn -vvv returns the following for the HVR-1600 Card

> 01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
> CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog
> Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: Hauppauge
> computer works Inc. WinTV HVR-1600 [0070:7444] Control: I/O- Mem+
> BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR-
> FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 
> Latency: 64 (500ns min, 50000ns max), Cache Line Size: 32 bytes 
> Interrupt: pin A routed to IRQ 17 Region 0: Memory at f4000000
> (32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital
> Product Data Not readable Capabilities: [4c] Power Management
> version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
> DSel=0 DScale=0 PME- Kernel driver in use: cx18 Kernel modules:
> cx18


2.  Links on Google to files related to this issue :
A. The Main Can on the Tuner Card -
       https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
B. First of the Conextant Chips on Card -
       https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
C. Second of the Conextant Chips on Card -
       https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
D. A Final ESMT Chip on Card -
       https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc
E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
       https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k
F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
       https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA

3.  I tested with both the SVideo and Coax Inputs for Analog.  As
you'll see from the 10 second videos the SVideo works fine but the
Coax Tuner is a problem.

4.  I don't know if I am capturing raw for MPEG compressed for certain
but I'll go over the test method used to make to two videos and that
should also answer this question.

5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat
commands for testing.

6.  Commands issued in order were as follows for the SVideo Capture:
    A. v4l2-ctl --list-devices
    B. v4l2-ctl -d /dev/video2 --list-inputs
    C. v4l2-ctl -d /dev/video2 --set-input=1  {Note this is SVideo1}
    D. v4l2-ctl -d /dev/video2 --list-standards | less
    E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
    F. mplayer /dev/video2 -cache 8192
    G. close mplayer after successfully watching video
    H. cat /dev/video2 > hvr1600-svideo1.mpg

7.  Commands issued in order were as follows for the Tuner1 Capture:
    A. v4l2-ctl --list-devices
    B. v4l2-ctl -d /dev/video2 --list-inputs
    C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
    D. v4l2-ctl -d /dev/video2 --list-standards | less
    E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
    F. v4l2-ctl -d /dev/video2 -f 67.250  {Note this is us-bdcst chan 4}
    G. mplayer /dev/video2 -cache 8192
    H. close mplayer after successfully watching video
    I. cat /dev/video2 > hvr1600-Tuner1.mpg

8.  It should be obvious by this point, but I am too much of a
neophyte to be compiling kernels.  I am running Centos 6 and yum for
updates for anything I have applied has come through their packaging
and distribution system.

NOTES : This SVideo looks good but the Tuner1 is garbage.  I also
tested the coax input thru my HVR-1850 using xawtv and while it had no
audio the video was good although slightly greenish.  So I don't
suspect the coax cable, especially since when connected to a standard
TV it produces a good picture.

Hope you can shed an idea or three.

My end goal it to again record analog video in MythTV.

Sincerely,
Bob Lightfoot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsZmpAAoJEKqgpLIhfz3XpXwIAKTIcmca98k3rbTU/T6Vz8LC
LCRI2J/ocFltV53QdPUOVmjmq/x3FTXZ1B1sSHcS6Av0fdDgU/GpDwp5aWv2apsv
lhUF6OtPFxylL8T9q23zPbZ3Io0p/PNzUTi/50LRYFXA+ATCn+AARoIiTHEOa1zW
ZEgvjETiCEKu5XxoRV8EUjITAR5F8KiiFeB+qdJkrpC0yee+R5rEL3Hvj3E5M+Cy
JbNRe7Su3SxcyaOVMaloxgIvreYaPmTlizBUKdKDphT9QnMIXQ8p55XiFNLX6jvo
ntaNaba0cm6sXzUjrSszgOUX4vj91hC/w5My6zkurLj19a9qog+iEFdHZoB3N6g=
=B7La
-----END PGP SIGNATURE-----

Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24

[Devin Heitmueller]

On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot <boblfoot@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Devin :
>      Let me see if I can answer some of your questions.
>
> 1. lspci -nn -vvv returns the following for the HVR-1600 Card
>
>> 01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
>> CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog
>> Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: Hauppauge
>> computer works Inc. WinTV HVR-1600 [0070:7444] Control: I/O- Mem+
>> BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR-
>> FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
>> DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 64 (500ns min, 50000ns max), Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 17 Region 0: Memory at f4000000
>> (32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital
>> Product Data Not readable Capabilities: [4c] Power Management
>> version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
>> DSel=0 DScale=0 PME- Kernel driver in use: cx18 Kernel modules:
>> cx18
>
>
> 2.  Links on Google to files related to this issue :
> A. The Main Can on the Tuner Card -
>        https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
> B. First of the Conextant Chips on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
> C. Second of the Conextant Chips on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
> D. A Final ESMT Chip on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc
> E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
>        https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k
> F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
>        https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA
>
> 3.  I tested with both the SVideo and Coax Inputs for Analog.  As
> you'll see from the 10 second videos the SVideo works fine but the
> Coax Tuner is a problem.
>
> 4.  I don't know if I am capturing raw for MPEG compressed for certain
> but I'll go over the test method used to make to two videos and that
> should also answer this question.
>
> 5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat
> commands for testing.
>
> 6.  Commands issued in order were as follows for the SVideo Capture:
>     A. v4l2-ctl --list-devices
>     B. v4l2-ctl -d /dev/video2 --list-inputs
>     C. v4l2-ctl -d /dev/video2 --set-input=1  {Note this is SVideo1}
>     D. v4l2-ctl -d /dev/video2 --list-standards | less
>     E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
>     F. mplayer /dev/video2 -cache 8192
>     G. close mplayer after successfully watching video
>     H. cat /dev/video2 > hvr1600-svideo1.mpg
>
> 7.  Commands issued in order were as follows for the Tuner1 Capture:
>     A. v4l2-ctl --list-devices
>     B. v4l2-ctl -d /dev/video2 --list-inputs
>     C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
>     D. v4l2-ctl -d /dev/video2 --list-standards | less
>     E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
>     F. v4l2-ctl -d /dev/video2 -f 67.250  {Note this is us-bdcst chan 4}
>     G. mplayer /dev/video2 -cache 8192
>     H. close mplayer after successfully watching video
>     I. cat /dev/video2 > hvr1600-Tuner1.mpg
>
> 8.  It should be obvious by this point, but I am too much of a
> neophyte to be compiling kernels.  I am running Centos 6 and yum for
> updates for anything I have applied has come through their packaging
> and distribution system.
>
> NOTES : This SVideo looks good but the Tuner1 is garbage.  I also
> tested the coax input thru my HVR-1850 using xawtv and while it had no
> audio the video was good although slightly greenish.  So I don't
> suspect the coax cable, especially since when connected to a standard
> TV it produces a good picture.
>
> Hope you can shed an idea or three.
>
> My end goal it to again record analog video in MythTV.

Ok, so this narrows it down quite a bit.  The fact that the s-video is
working but the tuner isn't suggests either the tuner is off tune, or
the analog demod isn't setup properly.  After running the "v4l2-ctl -s
1" command, do you see the standard set to NTSC-M if you then run
"v4l2-ctl --all" ?  Also, do you hear audio properly despite the video
being corrupt?

My guess is that some recent subtle change to the subdev framework is
probably resulting in the commands not actually being delivered to the
demod.  I ran into similar problems a few months ago when doing some
work on the cx18 driver for WSS configuration, although I didn't get a
chance to push any patches upstream.

Devin

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

Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24

[Devin Heitmueller]

On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot <boblfoot@gmail.com> wrote:
> Hope you can shed an idea or three.
>
> My end goal it to again record analog video in MythTV.

Two other questions:

Have you tried dropping the card into a Windows box to make sure your
hardware isn't just dead?  I know you said you thought it worked 6-9
months ago, but it's possible that it is just dumb luck that part of
the hardware died and it has nothing to do with the kernel revision.

Also, what kernel did it work last on?  If you could determine a
specific revision, it would help narrow down where the problem was
introduced (assuming it really is a regression in the kernel).

Devin

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

Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24

[Andy Walls]

On Sat, 2012-11-24 at 23:08 -0500, Bob Lightfoot wrote:
> Devin :
>      Let me see if I can answer some of your questions.
> 

> 
> 2.  Links on Google to files related to this issue :
> A. The Main Can on the Tuner Card -
>        https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
> B. First of the Conextant Chips on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
> C. Second of the Conextant Chips on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
> D. A Final ESMT Chip on Card -
>        https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc

Alright, this is one of the older card models.  They have been working
for quite a long while.

> E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
>        https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k

Looks good.

> F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
>        https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA

Blech.  Obviously an almost total loss of Horizontal Synchronization.
Vertical Synchronization appears to be OK, under the circumstances. 

FYI,  I normally associate the following conditions with signal level
going into the CX23418's integrated CX25843 A/V decoder:

- Good sound, bad video:     signal strength too low
- Bad/no sound, good video:  signal strength too high

Low video signal strength could explain why H-sync is lost.  However, it
also could be a DC voltage level building up on the CVBS signal trace
between the tuner and the CX23418 causing the CVBS signal (and the
H-sync pulse) to be floated upwards, such that the H-Sync pulse ins't
detected.

So here's what you need to do:

1. provide the output of v4l2-ctl -d /dev/video2 --log-status, so I can
see the analog tuner assembly that your unit has.

2. Test the unit under the previous Linux kernel version with which you
were *sure* the unit worked properly.  Or test with Windows as Devin
suggested.  We're trying to eliminate a bad HVR-1600 card here, so if
you can test it in that very same machine, all the better.

Also, if you can provide us with the two kernel versions, working and
non-working, we can narrow down if a kernel change caused the problem
for you.

3. Test with as few cards in the PC chassis as possible.  This will
eliminate some EMI and power supply problems.  It's a shot in the dark,
but easy enough for you to try.

4. If you do decide to much around in the PC, pull out all the PCI
cards, blow the dust out of all the slots, reseat the cards, and retest.
I am amazed at how often that actually helps with various problems.



I would point you to an email where I added all sorts of extra controls
to the cx18 driver in a patchset, for the express purpose of debugging
sync problems:

http://www.gossamer-threads.com/lists/ivtv/users/40227?do=post_view_threaded#40227

and ask you to fiddle around with them.

Unfortunately the patches, which are still here:

http://linuxtv.org/hg/~awalls/v4l-dvb-ctls/

are very old and don't apply cleanly to newer versions of the cx18
driver. :(


My suspicion is either 

a. you have a marginal CX23418 chip and something on you card or in your
chassis is allowing a DC charge to build up on the CVBS line between the
tuner and the CX23418

or

b. a recent kernel change broke the ananlog tuner configuration for the
tuner on your board.


> 3.  I tested with both the SVideo and Coax Inputs for Analog.  As
> you'll see from the 10 second videos the SVideo works fine but the
> Coax Tuner is a problem.
> 
> 4.  I don't know if I am capturing raw for MPEG compressed for certain
> but I'll go over the test method used to make to two videos and that
> should also answer this question.

It doesn't matter.  It looks like MPEG and not raw YUV, BTW.


> 5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat
> commands for testing.
> 
> 6.  Commands issued in order were as follows for the SVideo Capture:
>     A. v4l2-ctl --list-devices
>     B. v4l2-ctl -d /dev/video2 --list-inputs
>     C. v4l2-ctl -d /dev/video2 --set-input=1  {Note this is SVideo1}
>     D. v4l2-ctl -d /dev/video2 --list-standards | less
>     E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
>     F. mplayer /dev/video2 -cache 8192
>     G. close mplayer after successfully watching video
>     H. cat /dev/video2 > hvr1600-svideo1.mpg
> 
> 7.  Commands issued in order were as follows for the Tuner1 Capture:
>     A. v4l2-ctl --list-devices
>     B. v4l2-ctl -d /dev/video2 --list-inputs
>     C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
>     D. v4l2-ctl -d /dev/video2 --list-standards | less
>     E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
>     F. v4l2-ctl -d /dev/video2 -f 67.250  {Note this is us-bdcst chan 4}
>     G. mplayer /dev/video2 -cache 8192
>     H. close mplayer after successfully watching video
>     I. cat /dev/video2 > hvr1600-Tuner1.mpg
> 
> 8.  It should be obvious by this point, but I am too much of a
> neophyte to be compiling kernels.  I am running Centos 6 and yum for
> updates for anything I have applied has come through their packaging
> and distribution system.

Centos and other enterprise distros and clone usually run pretty old
kernels.  You may be running into a bug which was found and fixed years
ago.

Have you tried with a modern LiveCD of Fedora or Ubuntu or Knoppix or
something?  (I don't know which one has HVR-1600 support built into a
live CD.)

Regards,
Andy

> NOTES : This SVideo looks good but the Tuner1 is garbage.  I also
> tested the coax input thru my HVR-1850 using xawtv and while it had no
> audio the video was good although slightly greenish.  So I don't
> suspect the coax cable, especially since when connected to a standard
> TV it produces a good picture.
> 
> Hope you can shed an idea or three.
> 
> My end goal it to again record analog video in MythTV.
> 
> Sincerely,
> Bob Lightfoot

Poor HVR 1600 Video Quality - Feedback for Andy Walls 2012-11-26

[Bob Lightfoot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2012 07:54 PM, Andy Walls wrote:
> So here's what you need to do:
> 
> 1. provide the output of v4l2-ctl -d /dev/video2 --log-status, so I
> can see the analog tuner assembly that your unit has.
> 
Here is the output with the S-Video Input in use.  If I need to
snapshot with the coax input in use that will take a little more time.
Status Log:

   cx18-0: =================  START STATUS CARD #0  =================
   cx18-0: Version: 1.4.0  Card: Hauppauge HVR-1600
   tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 5267091
   tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93
   tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
   tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
   tveeprom 4-0050: audio processor is CX23418 (idx 38)
   tveeprom 4-0050: decoder processor is CX23418 (idx 31)
   tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter
   cx18-0 843: Video signal:              present
   cx18-0 843: Detected format:           NTSC-M
   cx18-0 843: Specified standard:        NTSC-M
   cx18-0 843: Specified video input:     S-Video (Luma In1, Chroma In5)
   cx18-0 843: Specified audioclock freq: 48000 Hz
   cx18-0 843: Detected audio mode:       mono
   cx18-0 843: Detected audio standard:   BTSC
   cx18-0 843: Audio muted:               no
   cx18-0 843: Audio microcontroller:     stopped
   cx18-0 843: Configured audio standard: automatic detection
   cx18-0 843: Configured audio system:   BTSC
   cx18-0 843: Specified audio input:     External
   cx18-0 843: Preferred audio mode:      stereo
   cx18-0 gpio-reset-ctrl: GPIO:  direction 0x00003001, value 0x00003001
   tuner 5-0061: Tuner mode:      analog TV
   tuner 5-0061: Frequency:       67.25 MHz
   tuner 5-0061: Standard:        0x0000b000
   cs5345 4-004c: Input:  2
   cs5345 4-004c: Volume: 0 dB
   cx18-0: Video Input: S-Video 1
   cx18-0: Audio Input: Line In 1
   cx18-0: GPIO:  direction 0x00003001, value 0x00003001
   cx18-0: Tuner: TV
   cx18-0: Stream: MPEG-2 Program Stream
   cx18-0: VBI Format: Private packet, IVTV format
   cx18-0: Video:  720x480, 30 fps
   cx18-0: Video:  MPEG-2, 4x3, Variable Bitrate, 4400000, Peak 6600000
   cx18-0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
   cx18-0: Audio:  48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No
Emphasis, No CRC
   cx18-0: Spatial Filter:  Manual, Luma 1D Horizontal, Chroma 1D
Horizontal, 0
   cx18-0: Temporal Filter: Manual, 8
   cx18-0: Median Filter:   Off, Luma [0, 255], Chroma [0, 255]
   cx18-0: Status flags: 0x00200001
   cx18-0: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64
buffers) in use
   cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
buffers) in use
   cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20
buffers) in use
   cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB
(256 buffers) in use
   cx18-0: Read MPEG/VBI: 0/0 bytes
   cx18-0: ==================  END STATUS CARD #0  ==================

> 2. Test the unit under the previous Linux kernel version with which
> you were *sure* the unit worked properly.  Or test with Windows as
> Devin suggested.  We're trying to eliminate a bad HVR-1600 card
> here, so if you can test it in that very same machine, all the
> better.
> 
> Also, if you can provide us with the two kernel versions, working
> and non-working, we can narrow down if a kernel change caused the
> problem for you.
> 
I do not have the ability to revert to a known working state without
potentially messing thigns up in a serious way.  I know the last known
good working state was prior to 2012-08-10.  I've tried reverting to
kernels that were current at that time and the problem still persist.
 It also is worth noting that the "good" video at that time still had
the occaisional artifact along the edges which does not happen using
the SVideo portion of the card now.

> 3. Test with as few cards in the PC chassis as possible.  This
> will eliminate some EMI and power supply problems.  It's a shot in
> the dark, but easy enough for you to try.
> 
I just finished a weeks vacation and after the honey-do list had
Friday, Saturday and Sunday to play on the video tower.  Pulled
everything apart and cleaned it all.  The pictures I took involved
removing and reseating all the cards so this did not help.  It will be
December before I have time to pull cards and try this as you suggest.
Must earn a paycheck.

> 4. If you do decide to much around in the PC, pull out all the PCI 
> cards, blow the dust out of all the slots, reseat the cards, and
> retest. I am amazed at how often that actually helps with various
> problems.
> 
> 
> 
> I would point you to an email where I added all sorts of extra
> controls to the cx18 driver in a patchset, for the express purpose
> of debugging sync problems:
> 
> http://www.gossamer-threads.com/lists/ivtv/users/40227?do=post_view_threaded#40227
>
>  and ask you to fiddle around with them.
> 
> Unfortunately the patches, which are still here:
> 
> http://linuxtv.org/hg/~awalls/v4l-dvb-ctls/
> 
> are very old and don't apply cleanly to newer versions of the cx18 
> driver. :(
> 
> 
> My suspicion is either
> 
> a. you have a marginal CX23418 chip and something on you card or in
> your chassis is allowing a DC charge to build up on the CVBS line
> between the tuner and the CX23418
> 
> or
> 
> b. a recent kernel change broke the ananlog tuner configuration for
> the tuner on your board.

I can agree that your theories are correct.  For now SVideo is working
so much better than coax ever did with mythtv that I an hesitant to
disturb things until my next vacation week in December.
> 
> 
> Centos and other enterprise distros and clone usually run pretty
> old kernels.  You may be running into a bug which was found and
> fixed years ago.
> 
> Have you tried with a modern LiveCD of Fedora or Ubuntu or Knoppix
> or something?  (I don't know which one has HVR-1600 support built
> into a live CD.)
> 
That sounds like a great idea.  I may just try and download a
mythbuntu live cd/dvd and boot it.  Should have the necessary drivers
since even my old Centos Kernels support the HVR-1600 natively
{allegely} :)

> Regards, Andy
> 

Thanks to you and Devin for the time to respond.  Sorry I don't have
more time to dedicate to this at this moment.  Suffice to say the
video quality from SVideo looks tons better than I've ever seen from
coax with this card.  So for time being thats going to be the solution.

Thanks again.

Bob Lightfoot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQs4YYAAoJEKqgpLIhfz3XARYH/2WdS+62TeWiIJIcUyQOUyO5
IhBgodbCBSs8KNSBVKzKGXOgbimcwbHmkixMV0lse6d47o2itSBWc+H2UMMnqCTr
nuUXrjJ17+0+yeceePXUyk7OqQxGGjr7I0VBxiLB3saTr65n3DxwDu2A6TijBZuM
13WlVRASmTj37VzfZdZDfWgsAOcgV+GpKvqszvjm1JF0XXpiRVfOPO2/AtcDr921
MAiBCXFN7T9yToMWySgLf8+ZL9/SRgI+iUhdxV2KYAhd9kZ0r9nKGs7CPxrEeK8h
wSM1FO9i15agNXrp6oAcNJM9IHRlLXV3VtmSd0KfKVBL7wp25XJzFKVCura3hgw=
=YwZm
-----END PGP SIGNATURE-----