Re: HVR 1600 Distortion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote:
> Thanks for the response!  Replies are in line.
> 
> On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote:
> > On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote:
> >> I've recently noticed some distortion coming from my hvr1600 when
> >> viewing analog channels.  It happens to all analog channels with some
> >> slightly better than others.  I am running Fedora 12 linux with kernel
> >> version 2.6.32.21-166.
> >
> >
> >> I know I need to include more information but I'm not sure what to
> >> include.  Any help would be appreciated.
> >
> > 1. Would you say the distortion is something you would possibly
> > encounter on an analog television set, or does it look "uniquely
> > digital"?  On systems with a long uptime and lots of usage, MPEG encoder
> > firmware could wind up in a screwed up state giving weird output image.
> > Simple solution in this case is to reboot.
> 
> I'm not sure if I would classify it as "uniquely digital".  The
> distortion happens across most of the screen with it being
> concentrated in the top third.  Additionally shows that include black
> bars the top black bar is seemingly stretched and the image seems like
> the colors are over-saturated where they colors are brighter.
> Rebooting had no effect :(

OK.

> > 2. Have you ensured your cable plant isn't affecting signal integrity?
> > http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
> 
> The cable plant hasn't changed the signal strength or integrity as far
> as I know.

OK.  Keep it in the back of your mind though.

> > 3. Does this happen with only the RF tuner or only CVBS or only SVideo
> > or more than one of them?  If the problem is only with RF, then it could
> > be an incoming signal distortion problem.  Do you have cable or an over
> > the air antenna for analog RF?
> 
> I only have input for the RF tuner.  I have cable for analog RF.

Please try and test the output of a VCR or DVD play plugged into the
HVR-1600.  (We don't need sound, just the video.)

This will tell us if the problem happens before the CX23418 chip's
analog front end (i.e. in the RF and analog tuner) or not.


$ v4l2-ctl -d /dev/video0 -n
(List of possible inputs displayed)

$ v4l2-ctl -d /dev/video0 -i 2
Video input set to 2 (Composite 1)

# v4l2-ctl -d /dev/video0 -s ntsc-m
Standard set to 00001000

$ cat /dev/video0 > foo.mpg
^C


> > 4. What does v4l2-ctl --log-status show as your analog tuner?
> 
> Not sure what you mean so I've included the full output:
> # v4l2-ctl -d /dev/hvr1600 --log-status
> 
> Status Log:
> 
>    cx18-0: =================  START STATUS CARD #0  =================
>    cx18-0: Version: 1.2.0  Card: Hauppauge HVR-1600
>    tveeprom 3-0050: Hauppauge model 74041, rev C6B2, serial# 898361
>    tveeprom 3-0050: MAC address is 00-0D-FE-0D-B5-39
>    tveeprom 3-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
                                     ^^^^^^^^^^^^^^
OK.  You have a board with the same tuner as I have.

All I have for an analog RF source is a DTV STB, so a very clean channel
3 is all I have to try and duplicate the problem.


>    tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08)
>    tveeprom 3-0050: audio processor is CX23418 (idx 38)
>    tveeprom 3-0050: decoder processor is CX23418 (idx 31)
>    tveeprom 3-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:     Composite 7
>    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:     running
>    cx18-0 843: Configured audio standard: automatic detection
>    cx18-0 843: Configured audio system:   BTSC
>    cx18-0 843: Specified audio input:     Tuner (In8)
>    cx18-0 843: Preferred audio mode:      stereo
>    cx18-0 gpio-reset-ctrl: GPIO:  direction 0x00003001, value 0x00003001
>    tuner 4-0061: Tuner mode:      analog TV
>    tuner 4-0061: Frequency:       175.25 MHz
                                    ^^^^^^
This is the freq for both US Broadcast and US Cable channel 7 BTW.


>    tuner 4-0061: Standard:        0x0000b000
>    cs5345 3-004c: Input:  1
>    cs5345 3-004c: Volume: 0 dB
>    cx18-0: Video Input: Tuner 1
>    cx18-0: Audio Input: Tuner 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, 6600000, Peak 6600000
>    cx18-0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
>    cx18-0: Audio:  48 kHz, MPEG-1/2 Layer II, 384 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 2048 KiB (16 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: 3507263488/15001920 bytes
>    cx18-0: ==================  END STATUS CARD #0  ==================
> 
> 
> > 5. Do you have a kernel with the new concurrency managed workqueues?
> > On these kernels 'ps axf' will *not* show kernel threads with names like
> > [cx18-0-in], [cx18-0-out/0], [cx18-0-out/1].  This is a major kernel
> > change which could cause some MPEG buffers to be lost or reordered, if
> > the new workqueue implementation has bugs.
> >
> ps axf shows [cx18-0-in], [cx18-0-out/0], [cx18-0-out/1],
> [cx18-0-out/2], [cx18-0-out/3]

OK.  That eliminates that potential source of problems.


> > 6. Have you recently installed new hardware in the subject computer?  Of
> > most interest are adapter cards with cables coming off of them and cards
> > very close to the HVR-1600.  EMI can be picked up by the HVR-1600's
> > board traces that are not shielded.
> >
> 
> Haven't changed any of the hardware in the system.

OK.

> > 7. Does the distortion look like loss of horizontal line sync and happen
> > only near very bright parts of the image on the left edge?  If it does,
> > the baseband video signal level is too high.
> 
> It does seem to be worse in brighter areas of the screen.  Inserting
> additional splitters (to reduce the signal strength) has no affect.

OK.  The problem I mentioned is usually for when you have a very good
picture otherwise.  If the entire image is poor, then this likely isn't
the cause.

> > 8. Care to post a short image in a paste bin or email a small MPEG to
> > me?
> 
> I've tried using $ ivtv-tune -c 71 -d /dev/hvr1600 followed by $ cat
> /dev/hvr1600 > /tmp/test.mpg then ctrl+c'ing that after a few seconds
> but it results in garbage.  Do you have a better method?

So try this:

1. Configure your system so they MythTV backend, or any other
application that messes with the video card, won't start up on reboot.

2. Shutdown the machine & power-off & power back on.

3. Do these for steps for US Cable

$ v4l2-ctl -d /dev/video0 -i 0
Video input set to 0 (Tuner 1)

$ ivtv-tune -d /dev/video0 -t us-cable -c 7
/dev/video0: 175.250 MHz

$ cat /dev/video0 > foo.mpg


Note that v4l2-ctl and ivtv-tune default to "/dev/video0", but I see you
have a "/dev/hvr1600"(?).  In all my examples, I explicitly call out the
device node as "/dev/video0".  Please replace "/dev/video0" with the
appropriate device node name on your system.




>   I'll email
> you that file so you can see it anyway.  Most of my recordings are
> from using mythtv and the results are at least watchable.
> > Regards,
> > Andy
> >

Received it.  It looks really, really bad: like an untuned channel.
Please try again with the steps I provided explicitly calling out the
device node.

Thanks,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux