Re: [linux-dvb] Cannot switch polarization: Hauppauge WinTV-NOVA-HD-S2
On 21. feb.. 2008, at 18:03, Steven Toth wrote: 13V is vertical and 18V is horisontal polarization, so I don't think it is related. I have two HVR-4000 working on OpenSuse 10.3 with the latest v4l-dvb drivers from http://linuxtv.org/hg/v4l-dvb pathed with http://dev.kewl.org/hauppauge/v4l-dvb-hg-sfe-latest.diff. I have also followed the instructions you refer to, but had to do make release before the make and make install to get it to work. Someone started screwing with the isl1621 (?) driver after support for this product was released (probably to fix another vendors board), it broke Hauppauge support. Thanks for your help. Having checked voltage, I was stumped to why it was not working, and it turns out that one of the recievers in our 8- way LNB no longer tunes to the horisontal polarization. (Its been tuning to the same vertical polarized channel for the last 2.5 years, so I guess something broke.) I tested with another cable, and it was able to scan both vertical and horizontally polarized channels. Regards, -- Andreas Bergstrøm Østfold University College Dept. of Computer Sciences Tel: +47 69 21 53 71 http://media.hiof.no/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need Help with PCTV 452e (USB DVB-S2 device with STB0899)
Hi, -snip Great, that was the trick, now scanning and szap work fine. Thanks for that hint! You're welcome. BTW: do you receive broken streams (symbol rate 22000 or 27500)? Currently I get a loss of about 1 TS packet every second or even more (with both symbol rates). And there is exactly one TS packet missing (I diffed a TS hexdump). If it were the USB controller that drops packets it would be a loss of 5 consecutive TS packets. (940 bytes iso frame size) Thanks for testing, Dominik signature.asc Description: This is a digitally signed message part. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Need Help with PCTV 452e (USB DVB-S2 device with STB0899)
Dominik Kuhlen schrieb: Hi, -snip Great, that was the trick, now scanning and szap work fine. Thanks for that hint! You're welcome. BTW: do you receive broken streams (symbol rate 22000 or 27500)? Currently I get a loss of about 1 TS packet every second or even more (with both symbol rates). And there is exactly one TS packet missing (I diffed a TS hexdump). If it were the USB controller that drops packets it would be a loss of 5 consecutive TS packets. (940 bytes iso frame size) I will test it soon and give a report. Jens ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] support for key repeat with dib0700 ir receiver
Hi all, My remote seems to be totally working now, I've played around with the keymaps to set it all up nicely :) Thanks so much to everyone who helped out.. May end up posting some sort of howto to help any other users with my remote stuck in the same boat (although it doesn't seem to be a particularly common piece of hardware) Cheers, and thanks again MAtt ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] support for key repeat with dib0700 ir receiver
On Fri, 2008-02-22 at 19:56 +0900, Matthew Vermeulen wrote: Hi all, My remote seems to be totally working now, I've played around with the keymaps to set it all up nicely :) Thanks so much to everyone who helped out.. Happy to hear that. May end up posting some sort of howto to help any other users with my remote stuck in the same boat (although it doesn't seem to be a particularly common piece of hardware) This would be good. I really would like to understand the process properly. Could you write something either directly in the wiki, or send it to me by email, and I'll post it in the wiki. Thanks much, Nico ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
On Thu, 21 Feb 2008 20:38:09 -0500 Michael Krufky [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw The above message were generated by cx88-cards. So, as I said before, this were called _before_ running dvb_register, defined at cx88-dvb. The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on that point of the code. With this, analog support will never work. The proper fix is to enable xc3028 before enabling i2c, meaning to correct the code at cx88_pci_nano_init(). After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for the gate. The state should be i2c closed, for xc3028 to work. The following patch should fix: http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c Please test it, with i2c_scan=1, and post the results. Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
On Monday 18 February 2008, hermann pitton wrote: Hi Peter, Am Sonntag, den 17.02.2008, 14:28 +1100 schrieb Peter D.: Hi, I've finally gotten around to reading the code and trying to get my PCI MSI [EMAIL PROTECTED] A/D card auto detected. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? for that all I give some examples further below. Second clarification, PCI versus cardbus. They don't look anything like each other, but can they be logically interchangeable? If the code for a cardbus tuner happens to work for a PCI tuner is there anything wrong with referring to the PCI tuner as a cardbus device? No, we do such and vice versa, but then we add a comment PCI or cardbus version usually and another important compatible category is Mini PCI. You should also add LR306 as the board type. Looking at http://www.linuxtv.org/wiki/index.php/DVB-T_PCMCIA_Cards there does not appear to be any such thing as a SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS, despite the entry (number 94) in saa7134.h. Looking at http://www.linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#LifeView there is a PCI version - but there is no PCI version in saa7134.h. They do exist, see bttv-gallery.de, OK found it. also Mauro has already a MSI OEM version. They are special for DVB-T, since they switch the mode by a gpio pin and have the silent i2c connection to the tuner open and don't use the i2c gate of the tda8290 analog demod inside the saa7131e for DVB-T tuning. So the PCI version looks like a slightly dysfunctional cardbus device. Should SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS be changed to SAA7134_BOARD_FLYDVBT_HYBRID? No. Just also add PCI and LR306 to your comments. The gpio 21 is used for the TV/radio switch. The gpio 22 = 0 in the mask is used to switch the tuner AGC to the analog demod. On some cardbus version, which have the gpio 27 high, switching it to 0 turns the fan on, on yours it does nothing, since it is 0 anyway. I can safely ignore all of that? It appears that both PCI and cardbus versions of the Flytv duo exist and are listed in saa7134.h - despite slightly inconsistent punctuation; SAA7134_BOARD_FLYDVBTDUO versus SAA7134_BOARD_FLYDVBT_DUO_CARDBUS. Should SAA7134_BOARD_FLYDVBTDUO be changed to SAA7134_BOARD_FLYDVBT_DUO? Not related to your device. Subdevice is 0x0306 and you have 0x3306, but yes, these are in a different family of devices too. I just thought that I have found a very minor typo - an extra underscore in on of the constants would look more systematic to me. It is not important. I have an MSI [EMAIL PROTECTED] A/D PCI card that works with the option card=94 There appears to not be an entry in struct pci_device_id saa7134_pci_tbl[] in saa7134-cards.c for my card. There is a reference to a [EMAIL PROTECTED] DUO which I guess is a valid entry for a different card. Yes it is. Peter Missel bought some and added the entry. Duo in LifeView terminology means two separate tuners. One for analog TV/FM and one for DVB-T. LifeView terminology. The meaning might change might change and we have to live with it. I was hoping that there would be a technical definition. On the older Duo versions those two tuners were _not hybrid_ and different for analog TV and DVB-T. Only the newer Duo variants with tda8275A use two identical such tuners, but not in hybrid mode. One is always in analog and the other always in digital mode. The older types are out of production and using two still allows to have DVB-T and analog TV from the tuners at once. This is not possible with one single hybrid tuner. DVB-T and analog video from an external input, VCR tuner or something, is possible at once, but needs also to use packed video formats for analog during that due to limitations of the dma engines with planar formats. Then the Trio has even one more tuner for DVB-S, but there is only _one_ saa713x PCI bridge on all such and only one channel decoder/demodulator for each mode. Since the single saa713x chip has only one TS/mpeg/host interface, either usable in parallel or serial mode, DVB-S and DVB-T can not be used at the same time. (also not an mpeg encoder) This is only possible with two saa713x bridges, like the md7134 in the CTX925 version has them and when we enable DVB-S support on the second bridge hopefully soon. Else functionality is like on the Trio. (BTW, the md7134 represents lots of different cards through eeprom detection) Next category is the Medion md8800 Quad(ro) with two saa7131e, two fully usable tda8275ac1 hybrid (2 analog + 2 DVB-T demods, no FM) and two tda8263 DVB-S tuners plus
Re: [linux-dvb] auto detection of Flytv duo/hybrid and pci/cardbus confusion
On Wednesday 20 February 2008, hermann pitton wrote: Am Sonntag, den 17.02.2008, 21:53 +0100 schrieb Peter Missel: Greetings all! Let me clear things up a bit. First clarification, duo versus hybrid. Are duo cards equipped with two independent tuners that can both be used at the same time? Are hybrid cards necessarily equipped with digital and analogue tuners? Can a two tuner card be both a duo and a hybrid, if one tuner is digital the other is analogue and they can both be used at the same time? LifeView are using two vendor IDs - 4E42h for all (!) their OEMs, and their own one for LifeView branded cards. Hence we need two PCI ID entries for everything, each pair pointing back to the same card data. Then, card types. The analog-only and hybrid have one single tuner, for DVB-T or analog. The Duo cards have two tuner frontends, one for DVB-T and the other for analog. Trio cards add a DVB-S frontend, which cannot be used at the same time as the DVB-T frontend. Like the Duo, these can run one digital and one analog stream in parallel. Finally, card shapes. Each card type comes in CardBus, PCI, and MiniPCI shape. The flavors are compatible, so that again, the PCI ID data point back to the same card entry for e.g. the PCI and CardBus Duo. The card type/shape combinations are distinctly identified by their subsystem ID. No need to guesstimate anything. That's the plan at least. regards, Peter Hi Peter! Your plan is fine so far. We might add some more comments to group devices obviously together, since those looking first time at it are a bit lost. For such i2c IR limits, we have your and Eddi's comments. Since we can't help it easily, Peter D. should suggest the older version of the MSI A/D for auto detection. It won't make anything more worse on that not fully clear Vivanco stuff, except Hartmut might have ideas. Cheers, Hermann I think that you just suggested something. I'm going to stand at the side and nod my head. ;-) What should I do to make it an official suggestion? -- sig goes here... Peter D. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
Mauro Carvalho Chehab wrote: On Thu, 21 Feb 2008 20:38:09 -0500 Michael Krufky [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw The above message were generated by cx88-cards. So, as I said before, this were called _before_ running dvb_register, defined at cx88-dvb. The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on that point of the code. With this, analog support will never work. The proper fix is to enable xc3028 before enabling i2c, meaning to correct the code at cx88_pci_nano_init(). After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for the gate. The state should be i2c closed, for xc3028 to work. The following patch should fix: http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c Please test it, with i2c_scan=1, and post the results. Doesn't work. [ 795.056020] Linux video capture interface: v2.00 [ 798.235564] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 798.235643] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 18 [ 798.235718] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 798.235722] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 798.371224] cx88[0]: i2c scan: found device @ 0x32 [???] [ 798.371391] cx88[0]: i2c scan: found device @ 0x34 [???] [ 798.399887] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] [ 798.400319] cx88[0]: i2c scan: found device @ 0xa2 [???] [ 798.400482] cx88[0]: i2c scan: found device @ 0xa4 [???] [ 798.400642] cx88[0]: i2c scan: found device @ 0xa6 [???] [ 798.400800] cx88[0]: i2c scan: found device @ 0xa8 [???] [ 798.400957] cx88[0]: i2c scan: found device @ 0xaa [???] [ 798.401116] cx88[0]: i2c scan: found device @ 0xac [???] [ 798.401272] cx88[0]: i2c scan: found device @ 0xae [???] [ 798.411996] cx88[0]: i2c scan: found device @ 0xd6 [???] [ 798.488821] Closing s5h1409 i2c gate to allow xc3028 detection [ 798.489283] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 798.489301] cx88[0]/0: found at :02:07.0, rev: 5, irq: 18, latency: 64, mmio: 0xe400 [ 798.489376] cx88[0]/0: registered device video0 [v4l2] [ 798.489408] cx88[0]/0: registered device vbi0 [ 818.236239] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [ 818.236443] cx88[0]/2: cx2388x 8802 Driver Manager [ 818.236465] ACPI: PCI Interrupt :02:07.2[A] - GSI 19 (level, low) - IRQ 18 [ 818.236480] cx88[0]/2: found at :02:07.2, rev: 5, irq: 18, latency: 64, mmio: 0xe600 [ 818.254906] cx88/2: cx2388x dvb driver version 0.0.6 loaded [ 818.254913] cx88/2: registering cx8802 driver, type: dvb access: shared [ 818.254918] cx88[0]/2: subsystem: 18ac:d530, board:
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
Michael Krufky wrote: Mauro Carvalho Chehab wrote: On Thu, 21 Feb 2008 20:38:09 -0500 Michael Krufky [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: It is not that simple. Steven patch works for DTV on PCI Nano; Christopher patches for some other DiVCO boards (DTV also); my port of Markus patch for other boards (tested by Dâniel Fraga - Analog TV). What does one board have to do with another? Just because these boards all use xceive tuners does not mean that they should be grouped together. No, but we have patches for all of them. Because the user has the ability to load cx8800 without cx88-dvb, and likewise, the user has the ability to load cx88-dvb without cx8800, the attach call must be fully qualified such that the other side of the driver is not required to be loaded in order for the tuner to work. If you take a look at the code, you'll see that all code is at cx88xx. This module is loaded by cx8800, if you're using analog, or by cx8802, if you're using cx88-dvb or cx88-blackbird. The code initializes xc3028 before tuner attach. In the case of FusionHDTV5 pci nano, there will never be an attach call from the analog side of the driver, since the tuner is hidden behind the s5h1409's i2c gate, and analog mode is not supported with the current driver. If you set i2c_scan=1 on the PCI nano, the xceive tuner will not even show up in the scan. The proper fix is to open the i2c gate before loading tuner. This will allow i2c_scan to work and both analog and digital modes will work. Btw, this somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards. I've added a patch that should open the bridge for s5h1409. Please test. Mauro, It does not work. See my prior email in this thread for the explanation. [ 2912.355967] Linux video capture interface: v2.00 [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 17 [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw The above message were generated by cx88-cards. So, as I said before, this were called _before_ running dvb_register, defined at cx88-dvb. The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on that point of the code. With this, analog support will never work. The proper fix is to enable xc3028 before enabling i2c, meaning to correct the code at cx88_pci_nano_init(). After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for the gate. The state should be i2c closed, for xc3028 to work. The following patch should fix: http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c Please test it, with i2c_scan=1, and post the results. Doesn't work. [ 795.056020] Linux video capture interface: v2.00 [ 798.235564] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded [ 798.235643] ACPI: PCI Interrupt :02:07.0[A] - GSI 19 (level, low) - IRQ 18 [ 798.235718] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI Nano [card=59,autodetected] [ 798.235722] cx88[0]: TV tuner type 71, Radio tuner type -1 [ 798.371224] cx88[0]: i2c scan: found device @ 0x32 [???] [ 798.371391] cx88[0]: i2c scan: found device @ 0x34 [???] [ 798.399887] cx88[0]: i2c scan: found device @ 0xa0 [eeprom] [ 798.400319] cx88[0]: i2c scan: found device @ 0xa2 [???] [ 798.400482] cx88[0]: i2c scan: found device @ 0xa4 [???] [ 798.400642] cx88[0]: i2c scan: found device @ 0xa6 [???] [ 798.400800] cx88[0]: i2c scan: found device @ 0xa8 [???] [ 798.400957] cx88[0]: i2c scan: found device @ 0xaa [???] [ 798.401116] cx88[0]: i2c scan: found device @ 0xac [???] [ 798.401272] cx88[0]: i2c scan: found device @ 0xae [???] [ 798.411996] cx88[0]: i2c scan: found device @ 0xd6 [???] [ 798.488821] Closing s5h1409 i2c gate to allow xc3028 detection [ 798.489283] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw [ 798.489301] cx88[0]/0: found at :02:07.0, rev: 5, irq: 18, latency: 64, mmio: 0xe400 [ 798.489376] cx88[0]/0: registered device video0 [v4l2] [ 798.489408] cx88[0]/0: registered device vbi0 [ 818.236239] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded [ 818.236443] cx88[0]/2: cx2388x 8802 Driver Manager [ 818.236465] ACPI: PCI Interrupt :02:07.2[A] - GSI 19 (level, low) - IRQ 18 [ 818.236480] cx88[0]/2: found at :02:07.2, rev: 5, irq: 18, latency: 64, mmio:
Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?
On Friday 22 February 2008 8:13:44 am Michael Krufky wrote: warn_printk(Closing s5h1409 i2c gate to allow xc3028 detection\n); to: warn_printk(Closing s5h1409 i2c gate to allow xc3028 detection\n); I think you meant: warn_printk(core, Closing s5h1409 i2c gate to allow xc3028 detection\n); (which makes changeset 871db4e0451c compile for me) however, cx8802 still kernel-BUGs on me when loaded (see Re: New(ish) card support needed, sorta). -- Life is full of happy and sad events. If you take the time to concentrate on the former, you'll get further in life. Vanessa Ezekowitz [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] af9005 problem with frontend?
I have an unbranded USB DVB-T receiver bought off e-bay. It works in MS
Windows with blazevideo software OK, and according to the Windows driver it is
an af9005 device, and the documentation on the driver disk refers to Easy TV.
I'm trying to use it in Mandriva 2008.0 (kernel 2.6.22.18-desktop-1mdv) so I've
followed the instructions referred to at http://ventoso.org/luca/af9005/ to
download the latest v4l-dvb code, make and install it.
I plug in the USB stick and then attempt to use
$ dvbsnoop -s pidscan
but the only output I get is the announcement:
dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/
-
Transponder PID-Scan...
-
The dvbsnoop process then refuses to die - well so I thought till looking at
the dmesg output below. I am guessing the failure to attach a frontend is the
first problem - help please.
Output from dmesg:
usb 1-1: new full speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in cold state, will try to load a
firmware
dvb-usb: downloading firmware from file 'af9005.fw'
dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 32).
DVB: registering new adapter (Afatech DVB-T USB1.1 stick).
dvb-usb: no frontend was attached by 'Afatech DVB-T USB1.1 stick'
dvb-usb: Afatech DVB-T USB1.1 stick successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_af9005
BUG: unable to handle kernel NULL pointer dereference at virtual address
printing eip:
f8c60df7
*pde =
Oops: [#1]
SMP
Modules linked in: dvb_usb_af9005_remote dvb_usb_af9005 dvb_usb dvb_core
dvb_pll ipt_IFWLOG ipt_psd ip_set_iptree iptable_raw xt_comment xt_policy
xt_multiport ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_set ipt_SAME
ipt_REJECT ipt_REDIRECT ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG
ipt_iprange ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ip_set_portmap
ip_set_macipmap ip_set_ipmap ip_set_iphash ip_set xt_tcpmss xt_pkttype
xt_physdev xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac xt_limit xt_length
xt_helper xt_hashlimit ip6_tables xt_dccp xt_conntrack xt_CONNMARK xt_connmark
xt_CLASSIFY xt_tcpudp
xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_mangle
nfnetlink iptable_filter ip_tables x_tables usblp af_packet snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipv6 video
thermal sbs fan container button dock battery ac binfmt_misc loop nls_cp437
vfat fat nls_utf8 ntfs dm_mod usb_storage scsi_mod floppy cpufreq_ondemand
cpufreq_conservative cpufreq_powersave freq_table processor irda_usb irda
crc_ccitt snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_rhine
i2c_viapro i2c_core soundcore mii ehci_hcd uhci_hcd usbcore via_agp agpgart
ide_cd evdev tsdev shpchp pci_hotplug ext3 jbd ide_disk via82cxxx siimage
ide_core
CPU:0
EIP:0060:[f8c60df7]Not tainted VLI
EFLAGS: 00210297 (2.6.22.18-desktop-1mdv #1)
EIP is at af9005_generic_read_write+0x77/0x1e0 [dvb_usb_af9005]
eax: f4ccd000 ebx: 0001 ecx: edx: b003
esi: edi: 0001 ebp: d7391d8c esp: d7391d4c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process dvbsnoop (pid: 13298, ti=d739 task=cf0e9560 task.ti=d739)
Stack: 0002 f4ccd000 000200d2
0c2e b003 f4ccd000
d7391dac f8c6109d d7391da3 0001 0100 0001 f4ccd768
Call Trace:
[c010529a] show_trace_log_lvl+0x1a/0x30
[c010535b] show_stack_log_lvl+0xab/0xd0
[c0105551] show_registers+0x1d1/0x2d0
[c010575c] die+0x10c/0x240
[c0121399] do_page_fault+0x199/0x630
[c031599a] error_code+0x72/0x78
[f8c6109d] af9005_write_ofdm_register+0x3d/0xb0 [dvb_usb_af9005]
[f8c6139e] af9005_pid_filter_control+0x2e/0xd0 [dvb_usb_af9005]
[f8c61502] af9005_pid_filter+0xc2/0x140 [dvb_usb_af9005]
[f8c5b2fb] dvb_usb_ctrl_feed+0x6b/0x120 [dvb_usb]
[f8c5b3cd] dvb_usb_start_feed+0xd/0x10 [dvb_usb]
[f8c6d39c] dmx_ts_feed_start_filtering+0x4c/0xd0 [dvb_core]
[f8c6b0d1] dvb_dmxdev_filter_start+0xe1/0x390 [dvb_core]
[f8c6b4c7] dvb_demux_do_ioctl+0x147/0x400 [dvb_core]
[f8c6a10a] dvb_usercopy+0x8a/0x130 [dvb_core]
[f8c6ab3a] dvb_demux_ioctl+0x1a/0x20 [dvb_core]
[c018f455] do_ioctl+0x75/0xb0
[c018f6af]
[linux-dvb] Hauppauge WinTV Nova-T Stick problems
Hello, I recently bought a Sandberg DigiTV reciever with an af9015. I never got it to work. So now i bought a Hauppauge WinTV Nova-T Stick, because I read on the wiki that it would work. However I cannot get it to work. I have fetched the firmware dvb-usb-dib0700-1.10.fw (34306 bytes). When I use (dvb)scan I get tuning failed. If I boot up with the USB stick inserted, I get lots of IR recieving errors. The stick has an IR receiver, because it came with a remote. The device works in Windows Vista. Please answer if you have anything at all to say. Regards, Janus Troelsen dmesg.out.gz Description: GNU Zip compressed data lspci.out.gz Description: GNU Zip compressed data lsusb.out.gz Description: GNU Zip compressed data ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] HVR 4000 firmware not loaded?
Hello In Ubuntu 7.10 with kernel 2.6.22-14.47 I installed a Hauppauge HVR 4000. From http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 I made a driver update and a firmware update. In dmesg the card is recognized. In dvbsnoop are the current parameters not found dvbsnoop -s feinfo -pd 9 dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ DEMUX : /dev/dvb/adapter0/demux0 DVR : /dev/dvb/adapter0/dvr0 FRONTEND: /dev/dvb/adapter0/frontend0 - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: Conexant CX24116/CX24118 Frontend-type: QPSK (DVB-S) Frequency (min): 950.000 MHz Frequency (max): 2150.000 MHz Frequency stepsiz: 1.011 MHz Frequency tolerance: 5000 Symbol rate (min): 1.00 MSym/s Symbol rate (max): 45.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 4/5 FEC 5/6 FEC 6/7 FEC 7/8 FEC AUTO QPSK Current parameters: Error(95): frontend ioctl: Operation not supported following dmesg is the firmware not loaded Is the update procedure from http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 correct? Thanks in advance ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
James Klaas wrote: On 2/21/08, CityK [EMAIL PROTECTED] wrote: James Klaas wrote: HD capture .. HDMI/component/composite Whether it be done through an analog connection (eg. component) or digital connection (eg. HDMI/DVI/SDI), it all falls under the realm of the V4L subsystem, not DVB. Is that because it purports to capture the streams without compression? Or does that have more to do with a lack of a tuner? To be specific, its because the DVB API is about the reception of a Digital Video Broadcast, and those are made in form of a Transport Stream modulated onto a RF carrierconsequently, anything DVB entails a receiversecond thing to note is that, although the terminology capture is widely used in reference to digital applications just as much as it is with analog, it is a misnomer when it comes to DVBDVB devices are essentially network interfaces ... they are entirely akin to your computer's modem --- both have a receiver that acquires an RF siganl and then demodulates the underlying information of interest off that carrier wave. There is little difference between downloading a file from kernel.org, or Mircosoft, or from where ever, and saving that file to your hard disk, as there is to tuning to ABC, or PBS, or whatever station, and saving the TS or the underlying program stream (multiplexed within the TS) to your harddisk. So, turning to the examples quoted above: - Component: an analog signal that has nothing to do with DVB ... sure, you can build a DVB device that includes the facilities to capture component (and other analog sources) ... and by capture here, its meant that ADC has to be done first to convert the analog to a digital bitstream and then place it into a particular container format and save to disk but that aspect has nothing to do with DVB, and hence is covered by other subsystem (V4L) - HDMI: an uncompressed RGB or YUV digital bitstream ... not applicable to DVB ... sure, you can build a DVB device that includes the facilities to capture that digital bitstream...and by capture here, its meant that the stream is placed it in a particular container and saved to disk (either uncompressed or, if you so choose, with a codec -- either a lousy one or a loseless one) but that aspect has nothing to do with DVB, and hence should be covered by another subsystem (V4L) - DVI: same as HDMI - SDI (and in this case, you'd be interested specifically in HD-SDI, in SMPTE 372M): another uncompressed digital bitstream interface protocol ... comments are the same as the others In fact, speaking of what V4L would/should cover, see the first paragraph here: http://www.linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs About the only thing otherwise related to the DVB API would be the highly related DVB-ASI or SPI. Questions about extending the DVB API to include coverage of those were raised last year when Manu solicited suggestions on progression of the API; if you're really interested, see this lengthy thread here: http://marc.info/?l=linux-dvbm=118989203715847w=2 ) Partly what piqued my interest is there has been a great deal of talk about how capturing HD streams without compression is very difficult without very high end components, very expensive capture cards etc, etc. - Uncompressed is actually not very CPU intensive, but it is (a) HIGHLY bandwidth intensive and, consequently, (b) GIGANTICALLY_EXPENSIVE storage wise . It is very easy to describe both the bandwidth and, hence, storage considerations --- mathematically, for the video portion, its simply a Fn(frame size (i.e. resolution), frame rate, subsampling (i.e. 4:4:4, 4:2:2,...), and bit depth). To completely describe the rate, you can factor in the overhead requirements of the file container which you use, though its contribution to the total is entirely negligible compared to that of essence's. For an example of how to apply that knowledge to real world examples, read through from this post: http://forum.doom9.org/showthread.php?p=916752#post916752 - Compressed, on the other hand, is CPU Intensive It was surprising to me that you could in fact find something like this for less than $1000. With a card like this, it would be conceivable to create a HD capture system for well under a $1000. Computers are getting more powerful, and components are getting cheaperstill, there are more things to consider then meets the eye -- as that Doom9 thread alludes to, depending upon whether your trying uncompressed or compressed, there are storage considerations, sustained transfer rates to consider, codec issues, maybe digital restrictions management issues (with an interface like HDMI), processor considerations... The neat thing about the forthcoming Hauppauge device is that: - its analog (component) input ... thereby removing potential DRM considerations - and in addition to performing the ADC, the chip utilized is
Re: [linux-dvb] Avermedia PCIe combo tv card
CityK [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I was wondering on the status of support of the Avermedia PCIe OEM TV card. it's probly only used in gateway computers. no rush just wondering. thanx Did you find someone willing to work on support for it? Other wise the status will have not changed The point being, development around here is not done like a service centre where you submit an order ticket and then come back a little while later to see if its been filled. So you're going to have to be proactive, and try to secure help with the matter (and there are no guarantees that you will find such) if you are, yourself, unable to directly provide/contribute to the development of support for the device. Incidental to your device: - Mauro is continuing with efforts to further support for devices using XC3028 ... so you should heed attention to those developments - further to our earlier discussion about the MerlinC.rom, mkrufky informed me recently that it is actually for the CX23887 ... the CX23887 apparently has a CX2584x spliced/built into it, and the CX2584x requires a firmware. - in regards to the encoder portion, see stoth's comment here: http://marc.info/?l=linux-dvbm=120352870103836w=2 Sorry for being confused, I just thought that cards were put on a todo list. Ill update the wiki with the info on the merlinC.rom file. I got the remote from gateway free of charge, which is cool, but now I cant open it to get photos of it up on the wiki and since I ditched vista for M$ faster better supported OS windows xp pro I got no use for the remote, so its a ice looking paperweight. As far as contributing the only thing safe for me to do is testing, I looked at the cx23885 source code and figured I do a little copy paste rename to get it to stop saying its an unknown card and winced, my luck even though im in Linux I figured if I messed with the code long enough id end up with a windows blue screen of death. at least that's what happened when I tried to write a cpuid program in windows. sorry for getting of topic. thankx for your help. PS something with gateway written on it and a windows logo being a paperweight isn’t to suprising. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
CityK wrote: James Klaas wrote: On 2/21/08, CityK [EMAIL PROTECTED] wrote: James Klaas wrote: HD capture .. HDMI/component/composite Whether it be done through an analog connection (eg. component) or digital connection (eg. HDMI/DVI/SDI), it all falls under the realm of the V4L subsystem, not DVB. Is that because it purports to capture the streams without compression? Or does that have more to do with a lack of a tuner? To be specific, its because the DVB API is about the reception of a Digital Video Broadcast, and those are made in form of a Transport Stream modulated onto a RF carrier DVB isn't completely about a RF carrier. It is used in the studios, (interconnectivity) at the production levels (studios) as DVB-ASI as well. consequently, anything DVB entails a receiversecond thing to note is that, although the terminology capture is widely used in reference to digital applications just as much as it is with analog, it is a misnomer when it comes to DVB There are DVB-ASI transmitters too. DVB devices are essentially network interfaces ... they are entirely akin to your computer's modem --- both have a receiver that acquires an RF siganl and then demodulates the underlying information of interest off that carrier wave. This is true for DVB demods, not otherwise. Generally we see a lot of DVB demods, but doesn't mean it is just that alone. There is little difference between downloading a file from kernel.org, or Mircosoft, or from where ever, and saving that file to your hard disk, as there is to tuning to ABC, or PBS, or whatever station, and saving the TS or the underlying program stream (multiplexed within the TS) to your harddisk. So, turning to the examples quoted above: - Component: an analog signal that has nothing to do with DVB ... sure, you can build a DVB device that includes the facilities to capture component (and other analog sources) ... and by capture here, its meant that ADC has to be done first to convert the analog to a digital bitstream and then place it into a particular container format and save to disk but that aspect has nothing to do with DVB, and hence is covered by other subsystem (V4L) many newer DVB devices will switch over to a one single package concept where it will be one chip for all, in such cases, no V4L will exist for such devices, except for a vanilla TV out interface. Such devices feature a generic framebuffer under the Video subsystem (not to be confused with V4L), where devices might be handled. For V4L to work with devices that way, it will need to copy more from the other subsystems such as Video, DVB and ALSA since V4L alone is not any specific real subsystem pertaining to something in real life. V4L just originated as a means to tune Analog TV cards under Linux, which later went in a different tangent. - HDMI: an uncompressed RGB or YUV digital bitstream ... not applicable to DVB ... sure, you can build a DVB device that includes the facilities to capture that digital bitstream...and by capture here, its meant that the stream is placed it in a particular container and saved to disk (either uncompressed or, if you so choose, with a codec -- either a lousy one or a loseless one) but that aspect has nothing to do with DVB, and hence should be covered by another subsystem (V4L) - DVI: same as HDMI - SDI (and in this case, you'd be interested specifically in HD-SDI, in SMPTE 372M): another uncompressed digital bitstream interface protocol ... comments are the same as the others In fact, speaking of what V4L would/should cover, see the first paragraph here: http://www.linuxtv.org/v4lwiki/index.php/Development:_Video4Linux_APIs About the only thing otherwise related to the DVB API would be the highly related DVB-ASI or SPI. Questions about extending the DVB API to include coverage of those were raised last year when Manu solicited suggestions on progression of the API; if you're really interested, see this lengthy thread here: http://marc.info/?l=linux-dvbm=118989203715847w=2 ) Partly what piqued my interest is there has been a great deal of talk about how capturing HD streams without compression is very difficult without very high end components, very expensive capture cards etc, etc. - Uncompressed is actually not very CPU intensive, but it is (a) HIGHLY bandwidth intensive and, consequently, (b) GIGANTICALLY_EXPENSIVE storage wise . It is very easy to describe both the bandwidth and, hence, storage considerations --- mathematically, for the video portion, its simply a Fn(frame size (i.e. resolution), frame rate, subsampling (i.e. 4:4:4, 4:2:2,...), and bit depth). To completely describe the rate, you can factor in the overhead requirements of the file container which you use, though its contribution to the total is entirely negligible compared to that of essence's. For an
Re: [linux-dvb] Hauppauge WinTV Nova-T Stick problems
On Fri, Feb 22, 2008 at 04:39:05PM +0100, Ysangkok wrote: However I cannot get it to work. I have fetched the firmware dvb-usb-dib0700-1.10.fw (34306 bytes). When I use (dvb)scan I get tuning failed. Hi Ysangkok, I have a Nova-T Stick very similar to yours (mine has USB vendor:product ID 2040:7060 while yours is 2040:7070). Assuming the hardware is substantially the same, you might want to 'modprobe mt2060' and check for this line in the dmesg output: MT2060: successfully identified (IF1 = 1220) Cheers, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST (vp-1020a) driver broken w/explanation
Does anyone have any intention of ever fixing this or will we have to
patch the fix in forever?
On Wed, Jan 16, 2008 at 3:50 PM, VDR User [EMAIL PROTECTED] wrote:
Greetings.. I have tried a DST VisionPlus 1020a dvb-s card today for
the first time with a fresh copy of v4l (from today Jan. 16th). Upon
loading the drivers I got the following message in dmesg:
Linux video capture interface: v2.00
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 17) at :01:09.0, irq: 10, latency: 64, mmio: 0xdcfff000
bttv0: using: Twinhan DST + clones [card=113,insmod option]
bttv0: gpio: en=, out= in=00fefffe [init]
bttv0: tuner absent
bttv0: add subdevice dvb0
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
ACPI: PCI Interrupt :01:09.1[A] - Link [LNKB] - GSI 10 (level,
low) - IRQ 10
bt878_probe: card id=[0x0], Unknown card.
Exiting..
ACPI: PCI interrupt for device :01:09.1 disabled
bt878: probe of :01:09.1 failed with error -22
dvb_bt8xx: unable to determine DMA core of card 0,
dvb_bt8xx: if you have the ALSA bt87x audio driver installed, try removing
it.
dvb-bt8xx: probe of dvb0 failed with error -14
The card was known to be working the last time it was in a box so I
suspected something other then it meeting death by sitting in an
anti-static bag. After some searching I found a others experiencing
the same problem and one of them posted the following:
The root cause of the problem seems to be that the DST card does not
have PCI subsystem information configured: the bytes are just set to
zero in the PCI configuration space. The driver
linux/drivers/media/dvb/bt8xx/bt878.c checks for a set of subsystem
IDs and only proceeds with the configuration if it finds one from the
list.
I then found the following patch that had been applied to the driver:
==
http://linuxtv.org/hg/v4l-dvb/rev/97edfa0f7c94
changeset 5513: 97edfa0f7c94
parent 5061: d5f262a7b702
child 6079: 358a897c1c19
manifest: 97edfa0f7c94
--- a/linux/drivers/media/dvb/bt8xx/bt878.c Sun Jan 07 20:12:22 2007
-0500
+++ b/linux/drivers/media/dvb/bt8xx/bt878.c Sat Apr 14 10:24:15 2007
-0300
@@ -397,9 +397,7 @@ static struct cards card_list[] __devini
{ 0xdb1118ac, BTTV_BOARD_DVICO_DVBT_LITE, Ultraview
DVB-T Lite },
{ 0xd50018ac, BTTV_BOARD_DVICO_FUSIONHDTV_5_LITE, DViCO
FusionHDTV 5 Lite },
{ 0x20007063, BTTV_BOARD_PC_HDTV, pcHDTV
HD-2000 TV },
- { 0x00261822, BTTV_BOARD_TWINHAN_DST, DNTV Live!
Mini },
-
- { 0, -1, NULL }
+ { 0x00261822, BTTV_BOARD_TWINHAN_DST, DNTV Live!
Mini }
};
==
After re-adding the { 0, -1, NULL }, re-compiling/installing/loading
the drivers, I now have a confirmed working card and get the following
in dmesg:
Linux video capture interface: v2.00
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI Interrupt :01:09.0[A] - Link [LNKB] - GSI 10 (level,
low) - IRQ 10
bttv0: Bt878 (rev 17) at :01:09.0, irq: 10, latency: 64, mmio: 0xdcfff000
bttv0: using: Twinhan DST + clones [card=113,insmod option]
bttv0: gpio: en=, out= in=00fefffe [init]
bttv0: tuner absent
bttv0: add subdevice dvb0
bt878: AUDIO driver version 0.0.0 loaded
bt878: Bt878 AUDIO function found (0).
ACPI: PCI Interrupt :01:09.1[A] - Link [LNKB] - GSI 10 (level,
low) - IRQ 10
bt878_probe: card id=[0x0],[ NULL ] has DVB functions.
bt878(0): Bt878 (rev 17) at 01:09.1, irq: 10, latency: 64, memory: 0xdcffe000
DVB: registering new adapter (bttv0)
dst(0) dst_get_device_id: Recognise [DST-MOT]
DST type flags : 0x4 symdiv 0x8 firmware version = 1
dst(0) dst_get_mac: MAC Address=[00:00:00:00:00:00]
DVB: registering frontend 0 (DST DVB-S)...
I have double-checked just to be sure and have confirmed the card only
works with { 0, -1, NULL } included. Was the patch actually tested
before it was accepted? I almost threw the card out because of this
so I'm sure glad to discover the problem is in the driver! Hopefully
it can be fixed before other think they have a dead card when they
don't.
Thanks.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] HVR 4000 and usb webcam working together?
Hi, Im trying to get working on the same pc, mythtv over a HVR 4000 and a usb webcam (gspca drivers) in a fresh Ubuntu 7.10. Before installing the hvr 4000 driver the webcam works fine on /dev/video0, but when I install hvr 4000 drivers the dev/video0 belongs now to the DVB-T capturer and I cannot load or reinstall properly the webcam gspca drivers. I follow these steps in order to install hvr 4000 - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 Can anyone give me some advice on how I can achive both devices working. Thanks for your time, Dani ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
CityK wrote: Manu Abraham wrote: CityK wrote: To be specific, its because the DVB API is about the reception of a Digital Video Broadcast, and those are made in form of a Transport Stream modulated onto a RF carrier DVB isn't completely about a RF carrier. It is used in the studios, (interconnectivity) at the production levels (studios) as DVB-ASI as well. This is true, but the context was in regards to the DVB API. In any case, I had made mention_of/alluded_to ASI SPI later on. consequently, anything DVB entails a receiversecond thing to note is that, although the terminology capture is widely used in reference to digital applications just as much as it is with analog, it is a misnomer when it comes to DVB There are DVB-ASI transmitters too. Very true ... my focus/thought was on the end user at the time of writing ... but we should not loose sight of the complete picture -- which of course involves the broadcast delivery chain DVB devices are essentially network interfaces ... they are entirely akin to your computer's modem --- both have a receiver that acquires an RF siganl and then demodulates the underlying information of interest off that carrier wave. This is true for DVB demods, not otherwise. Generally we see a lot of DVB demods, but doesn't mean it is just that alone. I don't follow. Generally people think that since we deal with demods alone mostly, people think that is the start and that is the end. (Meant on a very general level) There is little difference between downloading a file from kernel.org, or Mircosoft, or from where ever, and saving that file to your hard disk, as there is to tuning to ABC, or PBS, or whatever station, and saving the TS or the underlying program stream (multiplexed within the TS) to your harddisk. So, turning to the examples quoted above: - Component: an analog signal that has nothing to do with DVB ... sure, you can build a DVB device that includes the facilities to capture component (and other analog sources) ... and by capture here, its meant that ADC has to be done first to convert the analog to a digital bitstream and then place it into a particular container format and save to disk but that aspect has nothing to do with DVB, and hence is covered by other subsystem (V4L) many newer DVB devices will switch over to a one single package concept where it will be one chip for all, in such cases, no V4L will exist for such devices, except for a vanilla TV out interface. Such devices feature a generic framebuffer under the Video subsystem (not to be confused with V4L), where devices might be handled. For V4L to work with devices that way, it will need to copy more from the other subsystems such as Video, DVB and ALSA since V4L alone is not any specific real subsystem pertaining to something in real life. V4L just originated as a means to tune Analog TV cards under Linux, which later went in a different tangent. While the move to multi-purpose, single IC devices is inevitable, the processing stages for the varying applications which the IC will perform (i.e. demodulation, encoding, ADC, etc) remain the same ... I don't see how V4L would be cut out of the block ... unless, of course, that means DVB means to expand its capabilities and/or absorbing some of those currently handled by V4L The in between stages will be masked out by larger stages which will wrap around them, thereby you don't see those small basic controls. As you see compared to the old days, you don't have that micro level controls anymore these days. Those are getting phased out at a reasonable pace, with more hardware doing those functionality of manual control. (features getting packed in to make look like something different) For example, When there is so much integration at such a stage, you feel silly including something gigantic for something too silly. In such a case for example of a TV output, you might not even need something that complex, for such a small feature. (to cite as a crude example, maybe a bad example, but i hope you get the idea) At these levels, the hardware to be used is much proprietary and Linux won't make much of a dent, where the users are quite used to their production environments with other OS and applications (such as Viz RT for example) since there isn't anything quite near or usable to this under Linux, nothing DVB or V4L will be seen in the public, though there (are/might be) some proprietary solutions at some intermittent stages, but nothing that will have a whole Linux concept in such areas of usage In such cases the hardware and hardware device drivers are of very little concern, but the main concern is about the virtual instruments implemented in software such as decks and other things and so on. A broadcast professional, never has the time to learn or work with applications stuck together with
Re: [linux-dvb] HVR 4000 and usb webcam working together?
Im trying to get working on the same pc, mythtv over a HVR 4000 and a usb webcam (gspca drivers) in a fresh Ubuntu 7.10. Before installing the hvr 4000 driver the webcam works fine on /dev/video0, but when I install hvr 4000 drivers the dev/video0 belongs now to the DVB-T capturer and I cannot load or reinstall properly the webcam gspca drivers. I follow these steps in order to install hvr 4000 - http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 Can anyone give me some advice on how I can achive both devices working. If you have 2 devices then the 1st one will take /dev/video0 and the next will take /dev/video1 usually. BTW. the /dev/video is not the DVB-T device.. its the Composite/Analog TV interface. What happens when you try and load the webcam after then HVR4000? Thanks ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB-T initial scan file for Santander, Spain
Hello. In the end, I did not need this file, because w_scan with the -X option already gave me a channels.conf ready to use with tzap; but since it is already created I send it to you. I hope this is the right place for this, I have never written to a mailing list before. Best regards and thanks a lot for your time and work. - ¿Con Mascota por primera vez? - Sé un mejor Amigo Entra en Yahoo! Respuestas. es-Santander Description: 2345679039-es-Santander ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hauppauge WinTV Nova-T Stick problems
Hello David, I modprobe'd mt2060, however it doesn't render any additional lines in dmesg. The module does show up in lsmod (attached). Anyway, I forgot to tell you that I _did_ compile the latest linux-dvb git tree (about three days ago), however I am using the default Ubuntu kernel (2.6.22-14-generic). However if I compiled my own linux-dvb I understood that I did not need to have the absolute latest kernel. Next time I reboot I'll check what makes it show all those error messages in dmesg. I have an old syslog which has all the error messages, which look like this: Feb 21 09:44:35 Gigabob kernel: [ 541.199844] dib0700: RC Query Failed Feb 21 09:44:35 Gigabob kernel: [ 541.199856] dvb-usb: error while querying for an remote control event. Feb 21 09:44:35 Gigabob kernel: [ 541.351680] dib0700: RC Query Failed Feb 21 09:44:35 Gigabob kernel: [ 541.351692] dvb-usb: error while querying for an remote control event. Feb 21 09:44:35 Gigabob kernel: [ 541.503522] dib0700: RC Query Failed Feb 21 09:44:35 Gigabob kernel: [ 541.503538] dvb-usb: error while querying for an remote control event. Feb 21 09:44:36 Gigabob kernel: [ 541.655351] dib0700: RC Query Failed And it goes on like that :P The full syslog is 2,5 MB. I can upload if you wan't it, but there is not anything special. Regards, Ysangkok 2008/2/22, David Santinoli [EMAIL PROTECTED]: On Fri, Feb 22, 2008 at 04:39:05PM +0100, Ysangkok wrote: However I cannot get it to work. I have fetched the firmware dvb-usb-dib0700-1.10.fw (34306 bytes). When I use (dvb)scan I get tuning failed. Hi Ysangkok, I have a Nova-T Stick very similar to yours (mine has USB vendor:product ID 2040:7060 while yours is 2040:7070). Assuming the hardware is substantially the same, you might want to 'modprobe mt2060' and check for this line in the dmesg output: MT2060: successfully identified (IF1 = 1220) Cheers, David lsmod Description: Binary data ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
Hi. Am Samstag, den 23.02.2008, 03:35 +0400 schrieb Manu Abraham: CityK wrote: Manu Abraham wrote: CityK wrote: ... For V4L to work with devices that way, it will need to copy more from the other subsystems such as Video, DVB and ALSA since V4L alone is not any specific real subsystem pertaining to something in real life. V4L just originated as a means to tune Analog TV cards under Linux, which later went in a different tangent. While the move to multi-purpose, single IC devices is inevitable, the processing stages for the varying applications which the IC will perform (i.e. demodulation, encoding, ADC, etc) remain the same ... I don't see how V4L would be cut out of the block ... unless, of course, that means DVB means to expand its capabilities and/or absorbing some of those currently handled by V4L The in between stages will be masked out by larger stages which will wrap around them, thereby you don't see those small basic controls. As you see compared to the old days, you don't have that micro level controls anymore these days. Those are getting phased out at a reasonable pace, with more hardware doing those functionality of manual control. (features getting packed in to make look like something different) For example, When there is so much integration at such a stage, you feel silly including something gigantic for something too silly. In such a case for example of a TV output, you might not even need something that complex, for such a small feature. (to cite as a crude example, maybe a bad example, but i hope you get the idea) Maybe some facts in between, instead of pure advertising. If you have that, sold per every single device painfully. http://search.ebay.de/ws/search/SaleSearch?sofocus=bssatitle=dvb+cisacat=-1%26catref%3DC5fbd=1catref=C6fscl=1sorefinesearch=1flt=9from=R14nojspr=ypfid=0fswc=1few=saprclo=saprchi=fss=1saslop=1sasl=b.e.t.t.e.r.s.h.o.p.p.i.n.gfls=4%26floc%3D1sargn=-1%26saslc%3D0salic=77saatc=77sadis=200fpos=fsct=sacur=0sacqyop=gesacqy=sabfmts=0fobfmt=1saobfmts=insifga10244=10425saslt=2ftrt=1ftrv=1sabdlo=sabdhi=saaff=afdefaultafan=afmp=fsop=1%26fsoo%3D1fcl=3frpp=50 You still need something like this. http://cgi.ebay.de/Neu-CAM-CI-MODUL-AlphaCrypt-Light-mit-Software-1-12_W0QQitemZ37642816QQihZ024QQcategoryZ77740QQssPageNameZWDVWQQrdZ1QQcmdZViewItem And still have exactly nothing. If it stays like that, this will likely have some new owners soon, but teach me better. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] How do you stream the entire MPEG-TS with dvbstream?
Hi everyone, I've just installed a new DViCO FusionHDTV dual digital 4 (which appears to the PC as two USB Zarlink ZL10353 DVB-T devices.) I'm trying to set up dvbstream to send the whole transport stream across the network to another PC, but I can't get this to work. If I do something like this: dvbstream -f 226500 -gi 16 -bw 7 512 650 Then it works fine, I get video and audio on the other PC and about 500kB/sec network use, but if I do this: dvbstream -f 226500 -gi 16 -bw 7 8192 Then the network use goes up to 1.7MB/sec but the picture and sound arrive corrupted, as if I have extremely bad reception. Using an old version of dvbstream with a Hauppauge Nova-T this works fine, except in that case I have 3MB/sec of network traffic with the same channel. It's almost as if the latest version of dvbstream doesn't correctly capture the whole MPEG-TS stream from the card. Has anyone else gotten this to work? Thanks, Adam. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help with Skystar HD2 (Twinhan VP-1041/Azurewave AD SP400 rebadge)
Simeon Simeonov wrote: Hi Gernot, I can confirm that I have similar experience to yours. By the way do you know if one can control from the soft side (register or some other means) the max current output for the card. I am having a problem when trying to tune with a rotor. On the Linux side the current seems to be capped at 300 mA as on the XP I see it goes to about 440 mA. I was still surprised that this card can supply less current than the 102g but we take what we get ... The card has an auxiliary power supply i/p, which should be connected, if you are using a larger load. With a higher load and if you draw power from the PCI bus, it could be bad, as there are some limitations to the current drawn from a PCI slot. Also, you can set the SEC chip for a different current limitation. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Help with Skystar HD2 (Twinhan VP-1041/Azurewave AD SP400 rebadge)
Gernot Pansy wrote: hy, have you tried some other channel on a diffrent multiplex? i have also troubles on 2 multiplexes, but i believe that's trough my bad signal strength (it's the same on windows). otherwise there have to be some initialization registers configured differently. manu is the only guy, how knows about that and can help you. It is a 1:1 clone of the 1040/1. Will add in the id's to the mantis tree. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
hermann pitton wrote: Hi. If it stays like that, this will likely have some new owners soon, but teach me better. Unfortunately, i updated my mail filters which had tagged all your mails as junk, to spam status. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HD capture
Am Samstag, den 23.02.2008, 11:09 +0400 schrieb Manu Abraham: hermann pitton wrote: Hi. If it stays like that, this will likely have some new owners soon, but teach me better. Unfortunately, i updated my mail filters which had tagged all your mails as junk, to spam status. Unencrypted HD currently has the sole function to sell subscriptions. Not to say it, _is_ spam. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
