> Hi Hans,
>
> On Fri, Jun 22, 2007 at 02:53:24PM +0200, Hans Verkuil wrote:
>> > ivtv:  ==================== START INIT IVTV ====================
>> > ivtv:  version 0.10.3 (tagged release) loading
>> > ivtv:  Linux version: 2.6.20.4 preempt mod_unload K7
>>
>> Can you upgrade to a 2.6.21 kernel? See if it still happens. If so, then
>> also test (after a reboot, so everything is cleanly setup) if just doing
>> 'cat /dev/video0 >foo.mpg' also shows the same artifacts (this
>> eliminates
>> MythTV as a possible, if unlikely, cause).
>
> OK, still the same problem:
>
> http://ward.vandewege.org/foo.mpg
>
> This is 2.6.21.5; modules freshly loaded without mythtv being started
> after a
> reboot:
>
> ivtv:  ==================== START INIT IVTV ====================
> ivtv:  version 0.10.3 (tagged release) loading
> ivtv:  Linux version: 2.6.21.5 preempt mod_unload K7
> ivtv:  In case of problems please include the debug info between
> ivtv:  the START INIT IVTV and END INIT IVTV lines, along with
> ivtv:  any module options, when mailing the ivtv-users mailinglist.
> ivtv0: Autodetected Hauppauge card (cx23415 based)
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
> ACPI: PCI Interrupt 0000:00:08.0[A] -> Link
> [LNKA] -> GSI 10 (level, low) -> IRQ 10
> ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes)
> ivtv0: Encoder revision: 0x02060039
> ivtv0: Decoder revision: 0x02020023
> input: i2c IR (Hauppauge) as /class/input/input2
> ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c
> driver #0]
> tveeprom 0-0050: Hauppauge model 48134, rev I321, serial# 6283360
> tveeprom 0-0050: tuner model is Philips FM1216 (idx 21, type 5)
> tveeprom 0-0050: TV standards PAL(B/G) (eeprom 0x04)
> tveeprom 0-0050: audio processor is MSP4418 (idx 25)
> tveeprom 0-0050: decoder processor is SAA7115 (idx 19)
> tveeprom 0-0050: has radio, has IR receiver, has no IR transmitter
> ivtv0: Autodetected Hauppauge WinTV PVR-350
> tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> saa7115 0-0021: saa7115 found (1f7115d0e100000) @ 0x42 (ivtv i2c driver
> #0)
> saa7127 0-0044: saa7127 found @ 0x88 (ivtv i2c driver #0)
> msp3400 0-0040: MSP4418G-A2 found @ 0x80 (ivtv i2c driver #0)
> msp3400 0-0040: MSP4418G-A2 supports nicam and radio, mode is autodetect
> and autoselect
> ivtv0: Registered device video0 for encoder MPEG (4 MB)
> ivtv0: Registered device video32 for encoder YUV (2 MB)
> ivtv0: Registered device vbi0 for encoder VBI (1 MB)
> ivtv0: Registered device video24 for encoder PCM audio (1 MB)
> ivtv0: Registered device radio0 for encoder radio
> ivtv0: Registered device video16 for decoder MPEG (1 MB)
> ivtv0: Registered device vbi8 for decoder VBI (1 MB)
> ivtv0: Registered device vbi16 for decoder VOUT
> ivtv0: Registered device video48 for decoder YUV (1 MB)
> ivtv0: loaded v4l-cx2341x-init.mpg firmware (155648 bytes)
> tuner 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
> ivtv0: Initialized Hauppauge WinTV PVR-350, card #0
> ivtv:  ====================  END INIT IVTV ====================
>
>> The most likely cause seems to be the saa7115 video digitizer and I know
>> some changes were made by others in this module. Back home I use the
>> 2.6.21 kernel and I don't think I've ever seen these artifacts. But to
>> be
>> honest I'm fairly certain that I've also tested with a 2.6.20 kernel in
>> the past and it worked fine with that kernel as well.
>
> Any other ideas? Apparently the 'black band' problem at the top of the
> screen
> is not gone as I had reported earlier, it still periodically shows up.

Do a clean reboot, run 'cat /dev/video0 >foo.mpg' and in another console
run 'v4l2-ctl --log-status' while the capture is in progress and mail the
output.

I'm home next weekend and I'll see if I can reproduce this. I'm getting
more reports about potential saa7115 problems, so this is something I need
to investigate.

BTW: can you also test this using the S-Video or Composite input instead
of the tuner input? If the same distortion happens with those inputs then
we can eliminate the tuner as the possible source.

Thanks,

        Hans


_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to