On Sunday 26 February 2006 10:13, Aristedes Maniatis wrote:
> I guess the problems are more annoying because many of the changes
> (eg. changing the name of the tuner device) cause problems for people
> who had working systems before. I come from a FreeBSD background, not
> Linux, so my expectations are a little different I suppose. FreeBSD
> tends to lag behind the cutting edge support for new devices
> (particularly non-server ones) but regression problems seem far fewer
> (and this isn't specific to the ivtv driver in my experience of the
> Linux world so far).
>
> This one bit me because I had a working system and a quick "emerge
> ivtv" broke it. My fault I guess, and I'll do what I can to help work
> it out and see if the ivtv can be improved. This isn't to belittle
> the great work behind the ivtv driver. I am sure it isn't easy
> without comprehensive documentation of the hardware.
>
> Anyhow, can anyone clarify the relationship between eeprom, tuner,
> ivtv and msp3400 and which versions of each are meant to work with
> different kernel versions, which ones should come from the ivtv
> source and which should be installed from the kernel?
For kernels <2.6.15 use the ivtv-supplied modules. For 2.6.15 you can
use either one, although I'd recommend using the kernel supplied
versions if you also have other TV cards to prevent conflicts. If the
PVR cards are the only ones present, then it doesn't matter as long as
you don't mix modules.
All these annoyances are the main reason why the driver should become
part of the kernel.
>
> Looks like for me I need to go back to 0.3.x and some (don't yet
> know) old kernel release. But before I do, is it worth me running
> ivtv in some sort of debug mode to gather more information about the
> exact nature of the problem?
>
> I probably only have a day or two before some members of the
> household rebel against not having TV... :-<
>From what I can gather your PVR150 is misdetected as a PVR250. The full
kernel log should be available in /var/log/messages, so it would help
me a lot if you can check there for the tveeprom messages like these:
tveeprom 6-0050: Hauppauge model 23559, rev D391, serial# 7742699
tveeprom 6-0050: tuner model is Philips FQ1216AME MK4 (idx 91, type 56)
tveeprom 6-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K)
(eeprom 0x74)
tveeprom 6-0050: second tuner model is Philips TEA5768HL FM Radio (idx
101, type 62)
tveeprom 6-0050: audio processor is CX25843 (idx 37)
tveeprom 6-0050: decoder processor is CX25843 (idx 30)
tveeprom 6-0050: has radio, has no IR remote
I'd also like to know what ivtv thinks you have. For that, run
ivtv-detect.
The probable cause of all the confusion is that the driver relies on the
PCI IDs of the card to detect what type it is. It turns out that that
is not very reliable and that instead the tveeprom info should be used.
The problem is that I don't fully know which models map to which card
type, so misdetections can happen.
However, I first need the info mentioned above before I can say if it is
really a misdetection problem.
You can also as a quick band-aid use the cardtype module option of ivtv.
In your case that should probably be cardtype=1,3 or cardtype=3,1
depending on whether the PVR250 or the PVR150 is detected first.
Hans
>
>
> Cheers
> Ari Maniatis
>
> On 26/02/2006, at 5:26 AM, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > Well, actually, the eeprom, tuner and msp3400 (and perhaps more,
> > but I cannot think of them) modules were already part of the kernel
> > before ivtv,
> > but were split off early in the development cycle of ivtv to speed
> > up development.
> >
> > The difficult part is now to merge these changes back into the
> > original
> > V4L modules, so they can eventually become part of the kernel
> > again. In my
> > opinion Hans is doing a great job working towards this goal...
> >
> > I believe that the biggest changes with regard to this merge
> > occured in
> > 0.4.1, but I'm not sure; could be 0.4.0 too...
> >
> > Regards,
> > Stanley.
> >
> >> On 25/02/2006, at 3:08 AM, Tyler Trafford wrote:
> >>> Yeah, but one of those is a PVR150, which does not have an
> >>> msp3400 in
> >>> it.
> >>
> >> Ah. That's helpful. I just tried moving back to 0.4.0 and kernel
> >>
> >> 2.6.14 and got a slightly different startup error:
> >> : drive cache: write back
> >>
> >> sdb:<6>ivtv0: i2c attach to card #0 ok [client=saa7115, addr=21]
> >> msp34xx: ivtv version
> >> msp34xx: init: chip=MSP3415D-B3, has NICAM support, simple (D)
> >> mode msp34xx: $Id$ compiled on: Feb 25 2006 00:32:38
> >> msp3410: daemon started
> >> ivtv0: i2c attach to card #0 ok [client=MSP3415D-B3, addr=40]
> >> sdb1
> >> Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
> >> ivtv0: loading /lib/modules/ivtv-fw-enc.bin
> >> ivtv0: loading /lib/modules/ivtv-fw-dec.bin
> >> ivtv0: Encoder revision: 0x02050032
> >> ivtv0: Decoder revision: 0x02020023
> >> ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers
> >> (4096KB total)
> >> ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers
> >> (2048KB total)
> >> ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB
> >> total)
> >> ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers
> >> (2048KB total)
> >> ivtv0: Create encoder radio stream
> >> tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) by
> >> ivtv i2c driver #0
> >> msp34xx: I/O error #1 (read 0x10/0x200)
> >> msp34xx: I/O error #2 (read 0x10/0x200)
> >> msp34xx: I/O error #3 (read 0x10/0x200)
> >> msp34xx: I/O error #1 (read 0x10/0x200)
> >> msp34xx: giving up, reseting chip. Sound will go off, sorry folks
> >> :-|
> >>
> >>
> >> Because the dmesg buffer is being filled by those lines line
> >> repeating many times, that is actually the very top of the buffer
> >> so I can't see what came before. Strange that the CVS "$Id" tag is
> >> in there.
> >>
> >> I might have to try and go back to 0.3.x where everything worked
> >> fine. At what kernel/ivtv versions did msp3400 move into the
> >> kernel?
> >>
> >> Cheers
> >> Ari Maniatis
> >>
> >>
> >>
> >>
> >> -------------------------->
> >> ish
> >> http://www.ish.com.au
> >> Level 1, 30 Wilson Street Newtown 2042 Australia
> >> phone +61 2 9550 5001 fax +61 2 9550 4001
> >> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
> >>
> >>
> >>
> >> _______________________________________________
> >> ivtv-devel mailing list
> >> [email protected]
> >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
> >
> > _______________________________________________
> > ivtv-devel mailing list
> > [email protected]
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
