I fixed my problem by reverting back to the 2.6.13.2 kernel with ivtv 
0.4.0. I copied the firmware from an old version of KnoppMyth that did 
work and used it with kernel 2.6.18 (or >) with a very new ivtv and it 
didn't solve the problem, so my problem is not in the firmware, and not 
in the hardware, but rather a bug in ivtv / the kernel.

I'm trying a more recent version of KnoppMyth (August 2006) and if that 
works fine, I'll have greatly narrowed the range of versions where the 
bug was introduced.

- Christopher Thielen

Christopher Thielen wrote:
> I originally built a FC4 MythTV box back around Oct. '05 or so. I'm 
> going to try a version of KnoppMyth from December 2005 to recreate that 
> old software and see if I can't confirm that my hardware does or does 
> not work. I think if the problem persists even when using software from 
> ~summer 2005, it could just be a hardware problem. I hope not, but the 
> card has been used almost constantly for the last 1.5 years.
>
> I'll let you know. If my hardware does work under a different setup, 
> then we'd have a software bug, right? I did consider that since this 
> problem is prevalent in google searches, that it must be something 
> specific to my setup (such as a broken card).
>
> I'll let you know. Regardless, you've been a real help, thank you.
>
> - Christopher Thielen
>
> Hans Verkuil wrote:
>   
>> On Wednesday 22 August 2007 02:58:51 Christopher Thielen wrote:
>>   
>>     
>>> I had to change the mplayer line from pal to ntsc, and that's all I
>>> changed, so I ran:
>>>
>>> mplayer -demuxer rawvideo -rawvideo ntsc:format=hm12 /dev/video32
>>>
>>> Earlier in the day, video appeared just fine in the mplayer window,
>>>     
>>>       
>> So no 'tearing' like you got when capturing from video0? If you first 
>> use video32 for a minute, then stop mplayer and 
>> start 'mplayer /dev/video0' does the tearing reappear? That might 
>> indicate a problem with the compression phase and not with the cx2584x.
>>
>>   
>>     
>>> but I checked it later on in the day and I got this weird image where
>>> 2/3s of the screen was used by the channel I wanted (I used
>>> ivtv-tune) and another channel took up a different 1/3. The exact
>>> same command that produced this produced a perfect image hours
>>> earlier. Here is a picture of what I'm talking about:
>>> http://chris.luethy.net/get_photo.php?id=670
>>>     
>>>       
>> I think it is wise that you either test your card under Windows or go 
>> back to the old situation. Basically I need to have proof that the card 
>> isn't broken. I've never seen this sort of issues before and especially 
>> the results of this test suggest a hardware problem to me. There is 
>> nothing special about your card so if this was a driver problem then 
>> I'd expect to get many bug reports about this.
>>
>> Regards,
>>
>>      Hans
>>
>>   
>>     
>>> Also, while this corrupt mplayer was running, I ran the v4l2-ctl
>>> --log-status command. Here is it's output:
>>>
>>>
>>> Status Log:
>>>
>>>    ivtv0: =================  START STATUS CARD #0  =================
>>>    ivtv0: Version: 1.1.0 Card: WinTV PVR 500 (unit #1)
>>> <4>ivtv0: All encoder YUV stream buffers are full. Dropping data.
>>> <4>ivtv0: Cause: the application is not reading fast enough.
>>>    tveeprom 1-0050: Hauppauge model 23552, rev D492, serial# 8023885
>>>    tveeprom 1-0050: tuner model is Philips FQ1236A MK4 (idx 92, type
>>> 57) tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
>>>    tveeprom 1-0050: second tuner model is Philips TEA5768HL FM Radio
>>> (idx 101, type 62)
>>>    tveeprom 1-0050: audio processor is CX25843 (idx 37)
>>>    tveeprom 1-0050: decoder processor is CX25843 (idx 30)
>>>    tveeprom 1-0050: has radio, has no IR receiver, has no IR
>>> transmitter tda9887 1-0043: Data bytes: b=0xd4 c=0x30 e=0x44
>>>    cx25840 1-0044: Video signal:              present
>>>    cx25840 1-0044: Detected format:           NTSC-M
>>>    cx25840 1-0044: Specified standard:        NTSC-M
>>>    cx25840 1-0044: Specified video input:     Composite 7
>>>    cx25840 1-0044: Specified audioclock freq: 48000 Hz
>>>    cx25840 1-0044: Detected audio mode:       stereo
>>>    cx25840 1-0044: Detected audio standard:   BTSC
>>>    cx25840 1-0044: Audio muted:               no
>>>    cx25840 1-0044: Audio microcontroller:     running
>>>    cx25840 1-0044: Configured audio standard: automatic detection
>>>    cx25840 1-0044: Configured audio system:   BTSC
>>>    cx25840 1-0044: Specified audio input:     Tuner (In8)
>>>    cx25840 1-0044: Preferred audio mode:      stereo
>>>    wm8775 1-001b: Input: 2
>>>    ivtv0: Video Input:  Tuner 1
>>>    ivtv0: Audio Input:  Tuner 1
>>>    ivtv0: Tuner:  TV
>>>    ivtv0: Stream: MPEG-2 Program Stream
>>>    ivtv0: VBI Format: Private packet, IVTV format
>>>    ivtv0: Video:  480x480, 30 fps
>>>    ivtv0: Video:  MPEG-2, 4x3, Variable Bitrate, 4500000, Peak
>>> 6000000 ivtv0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
>>>    ivtv0: Audio:  48 kHz, Layer II, 384 kbps, Stereo, No Emphasis, No
>>> CRC ivtv0: Spatial Filter:  Manual, Luma 1D Horizontal, Chroma 1D
>>> Horizontal, 0
>>>    ivtv0: Temporal Filter: Manual, 0
>>>    ivtv0: Median Filter:   Off, Luma [0, 255], Chroma [0, 255]
>>>    ivtv0: Status flags:    0x00200000
>>>    ivtv0: Stream encoder MPG: status 0x0000, 0% of 4096 KiB (128
>>> buffers) in use
>>>    ivtv0: Stream encoder YUV: status 0x0118, 98% of 2056 KiB (195
>>> buffers) in use
>>>    ivtv0: Stream encoder VBI: status 0x0000, 0% of 1040 KiB (61
>>> buffers) in use
>>>    ivtv0: Stream encoder PCM: status 0x0000, 0% of 324 KiB (72
>>> buffers) in use
>>>    ivtv0: Read MPG/VBI: 13671132/58212 bytes
>>>    ivtv0: ==================  END STATUS CARD #0  ==================
>>>
>>> - Christopher Thielen
>>>
>>> Hans Verkuil wrote:
>>>     
>>>       
>>>> On Tuesday 21 August 2007 22:20:34 Christopher Thielen wrote:
>>>>       
>>>>         
>>>>> I switched to KnoppMyth a few days ago, and it had the needed
>>>>> kernel-devel packages.
>>>>>
>>>>> This compiled and installed fine, and I rebooted the system but
>>>>> unfortunately the problem persists.
>>>>>
>>>>> I should add that I believe the problem began after upgrading
>>>>> software, so it's possible using my old firmware (which I no
>>>>> longer have, but obtained around Oct. 2005) might solve the
>>>>> problem. Is this likely a firmware issue? Is there a place to
>>>>> obtain old firmware for the Hauppage PVR-500?
>>>>>         
>>>>>           
>>>> Do this test first using mplayer:
>>>>
>>>> mplayer -demuxer rawvideo -rawvideo pal:format=hm12 /dev/video32
>>>>
>>>> Does this show the same problem with the image? If so, then I'd say
>>>> it's unlikely to be a firmware problem. You can get older firmwares
>>>> here: http://dl.ivtvdriver.org/ivtv/firmware, but you'll have to
>>>> change the IVTV_FW_ENC_SIZE define in ivtv-firmware.c to
>>>> '(256*1024)' otherwise the older firmware won't load.
>>>>
>>>> Can you also show me the output of 'v4l2-ctl --log-status'?
>>>> Preferably while capturing.
>>>>
>>>> Thanks,
>>>>
>>>>    Hans
>>>>       
>>>>         
>>   
>>     
>
>
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>   


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

Reply via email to