Re: [linux-dvb] WinTV-NOVA-T-500 Status
On Tue, 2008-01-08 at 10:29 +0100, Patrick Boettcher wrote: Hi all, The new year starts well, maybe: We found something which was in our drivers from the beginning and nobody saw it. See attached. I'm not sure whether it fixes something, but it might be possible. Can everyone try it please? Latest tree synced, patch applied, modules compiled and installed, machine rebooted. (yeah for proper remote access and shell!) Let's see! I'll be back in Aberdeen tonight, and the wife and kids will loudly complain to me via cell phone if it doesn't work... Anyway, if this fixes the disconnects, an answer will not come overnight. Oh, and I updated the wiki page too, with info on this patch: http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-T-500 Nico http://www.youplala.net/linux/home-theater-pc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
On Donnerstag, 10. Januar 2008, John Drescher wrote: is there a way to somehow blacklist videobuf.ko w/o having to remove it? The reason is that packagewise this belongs to the kernel rpm which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I wouldn't want to nuke it - it would return anyway with the next kernel update. On gentoo there is a file: /etc/modprobe.d/blacklist for this purpose I have no idea on any other linux version. John Hi there! This file does just add the blacklist line into modprobe config file. But I doubt it will work for videodev-module as the original hotplug/udev event is not about videodev but about saa7134 module. So you maybe need to blacklist saa7134. Matthias -- Matthias Schwarzott (zzam) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] WinTV-CI from Hauppauge
Hi Steven, Am Donnerstag 20 Dezember 2007 20:20:46 schrieb Steven Toth: Luc Brosens wrote: all, so I got the WinTV-CI from Hauppauge. Nice little thing, powered through the USB(2)-port. On the box, is says Common-Interface extension over USB. Cool. There's software with it, but of course only XP and Vista... which are out of the question ;-) I'm contacting Hauppauge's tech support for specs, let's hope they're responsive. They won't be able to help, I can - but not for a few weeks. I'm expecting to release public USB protocol information during Jan 08 which would allow a GPL driver to be written. Right now I have nothing to give you. Are the documents coming soon? - Really looking forward to play around with this WinTV-CI. Regards, Julian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
hermann pitton wrote: Am Donnerstag, den 10.01.2008, 01:13 +0200 schrieb Axel Thimm: Hi, On Wed, Jan 09, 2008 at 11:42:19PM +0100, hermann pitton wrote: video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) Guess this is the root of the problem. Axel's modules might fail to eliminate it. Mauro has converted the old single videobuf.ko to different types to be more flexible. Looks like you have an upgrade to the new types without that the old videobuf.ko is removed from your /lib/modules.../media stuff. Try to remove/delete it manually and depmod -a. is there a way to somehow blacklist videobuf.ko w/o having to remove it? The reason is that packagewise this belongs to the kernel rpm which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I wouldn't want to nuke it - it would return anyway with the next kernel update. Instead maybe some dummy alias or some remapping could be made to effectively remove it from module-utils' radar w/o actually removing the file? That would be much cleaner from a packaging POV. Thanks! Hi Axel, here it is de facto gone, if not anymore in the next kernel release. What you do in between is up to you. If you like to stay in sync as close as possible, of course v4l-dvb counts and not the delayed kernel stuff. Greetings, Hermann I'm not sure what ideas people have about this after a spate of messages yesterday. The dmesg extracts that I posted were from a forced reboot after an improper shutdown and might not be 'typical', so I just risked a normal reboot from cold. This did not hang and has delivered a system that seems to be working properly, but during the udev phase and twice afterwards it reported on-screen that the video-buf.ko module was malformed. This is not recorded in dmesg. I then did an auto shutdown/reboot sequence, again without hanging but with the same malformed-module message. dmesg does still include repeated complaints about the duplicate symbol, as above, but there is no module videobuf.ko in the relevant directory. $ cd /lib/modules/2.6.18-53.1.4.el5/updates/drivers/media/video/ $ ls -l videobuf*.ko -rw-r--r-- 1 root root 23232 Dec 27 11:21 videobuf-core.ko -rw-r--r-- 1 root root 18120 Dec 27 11:21 videobuf-dma-sg.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-dvb.ko -rw-r--r-- 1 root root 11616 Dec 27 11:21 videobuf-vmalloc.ko and the 'malformed' module is not there $ ls -l video-buf*.ko ls: video-buf*.ko: No such file or directory The two dvb cards are saa7133[0]: subsystem: 1461:f01d, board: Avermedia Super 007 [card=117,autodetected] Thanks to all for your interest. I hope this helps. John Pilkington ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] NOVA-TD odd behaviour.
Hi, This is from my NovaTD stick, is something is odd. Sometimes when I tune a different channel on tuner1, reception on tuner 0 _seems_ to be affected. status 1f | signal 72b3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7229 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7260 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7322 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 70fe | snr | ber ebd0 | unc | FE_HAS_LOCK status 1f | signal 7134 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 714a | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7080 | snr | ber | unc | FE_HAS_LOCK *status 1f | signal 7051 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fda | snr | ber | unc | FE_HAS_LOCK* status 1f | signal 6fcb | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fc7 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fbc | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6f1b | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fc7 | snr | ber | unc | FE_HAS_LOCK So I started poking around a bit. Same channel (A), channel on both tuners at the same time. Tuner 0 status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK Tuner 1 status 1f | signal 716e | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7183 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71d8 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7174 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7170 | snr | ber | unc | FE_HAS_LOCK A different channel (B), but same on both tuners. Tuner 0 status 1f | signal 75ec | snr | ber | unc | FE_HAS_LOCK status 1f | signal 75e2 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7575 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7567 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7576 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7317 | snr | ber | unc | FE_HAS_LOCK Tuner 1 status 1f | signal 71f8 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7262 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71f3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71e2 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71f1 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7172 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7170 | snr | ber | unc | FE_HAS_LOCK So I figure my splitter is the cause of the problem. Antenna straight into the tuner, no splitter, channel A Tuner 0 status 1f | signal | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr | ber | unc | FE_HAS_LOCK Tuner 1 status 1f | signal 798b | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7988 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 78ad | snr | ber | unc | FE_HAS_LOCK status 1f | signal 783c | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7900 | snr | ber | unc | FE_HAS_LOCK Channel A, SVT1OLD:62600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1019:1018:1010 Channel B TV4 Uppland:47400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1049:1048:6100 I´m lost. /Henrik ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] NOVA-TD odd behaviour.
I inserted my Nova-T 500 SVTOLD == Channel A Tuner 0 [EMAIL PROTECTED]:~# tzap -a2 -c scan_file-HB SVT1OLD using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0' tuning to 62600 Hz video pid 0x03fb, audio pid 0x03fa status 0f | signal 8f03 | snr | ber 001f | unc 0013 | status 1f | signal 8ed5 | snr | ber | unc 008a | FE_HAS_LOCK status 1f | signal 8f18 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 8f3e | snr | ber | unc | FE_HAS_LOCK status 1f | signal 8f34 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 8f3f | snr | ber | unc | FE_HAS_LOCK status 1f | signal 8f78 | snr | ber | unc | FE_HAS_LOCK Tuner1 [EMAIL PROTECTED]:~# tzap -a3 -c scan_file-HB SVT1OLD using '/dev/dvb/adapter3/frontend0' and '/dev/dvb/adapter3/demux0' tuning to 62600 Hz video pid 0x03fb, audio pid 0x03fa status 07 | signal 9658 | snr | ber 001f | unc 0015 | status 1f | signal 967a | snr | ber | unc 00bd | FE_HAS_LOCK status 1f | signal 95c3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 95e3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 95b5 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 95ea | snr | ber | unc | FE_HAS_LOCK status 1f | signal 95af | snr | ber | unc | FE_HAS_LOCK status 1f | signal 9551 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 958a | snr | ber | unc | FE_HAS_LOCK status 1f | signal 95f3 | snr | ber | unc | FE_HAS_LOCK /Henrik On Jan 10, 2008 5:43 PM, Henrik Beckman [EMAIL PROTECTED] wrote: Hi, This is from my NovaTD stick, is something is odd. Sometimes when I tune a different channel on tuner1, reception on tuner 0 _seems_ to be affected. status 1f | signal 72b3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7229 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7260 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7322 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 70fe | snr | ber ebd0 | unc | FE_HAS_LOCK status 1f | signal 7134 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 714a | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7080 | snr | ber | unc | FE_HAS_LOCK *status 1f | signal 7051 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fda | snr | ber | unc | FE_HAS_LOCK * status 1f | signal 6fcb | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fc7 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fbc | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6f1b | snr | ber | unc | FE_HAS_LOCK status 1f | signal 6fc7 | snr | ber | unc | FE_HAS_LOCK So I started poking around a bit. Same channel (A), channel on both tuners at the same time. Tuner 0 status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK status 1e | signal | snr | ber | unc | FE_HAS_LOCK Tuner 1 status 1f | signal 716e | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7183 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71d8 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7174 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7170 | snr | ber | unc | FE_HAS_LOCK A different channel (B), but same on both tuners. Tuner 0 status 1f | signal 75ec | snr | ber | unc | FE_HAS_LOCK status 1f | signal 75e2 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7575 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7567 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7576 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7317 | snr | ber | unc | FE_HAS_LOCK Tuner 1 status 1f | signal 71f8 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 7262 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71f3 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71e2 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 71f1 | snr | ber | unc |
Re: [linux-dvb] Lockups with cx2388x cards
Peter Martin wrote: I have a couple of Hauppauge cards (Nova-T using the cx2388x and a Nova Plus, again using an cx2388x) in an industrial motherboard (an Axiomtek ATX6022-14G) which is causing me some grief. After a short time I am getting both cards locking up (no DMA) at the same time. Does it happen with only a single card active in the system? Have you tried the cards on other motherboards and do they operate successfully without error? In order to get these cards working at all in this configuration, I have re-arranged the SRAM and increased the FIFO size in cx88-core.c to 0x4800 bytes, and disabled all the other channels (video, audio etc), which has cured the FIFO overflow errors I was getting ( general errors: 0x0100), but the cards still lock up. The cards can run from between 5 seconds and 30 minutes before the lockup. I also get the lockups with the stock code, so I am happy that my SRAM chganges have not broken anything. IIRC, the fifo is pretty small (resulting in potential short latency issues). This could be compounded with a busy DMA bus and short fifo's both competing for the same DMA queue resource. I suspect increasing the fifo really just masks the real DMA contension issue. What else is happening DMA wise in your system? - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] BUG: can't rmmod budget_ci from multiproto
Hello, when I do a : rmmod cx88_alsa cx88xx cx24123 cx88_dvb cx88_vp3054_i2c cx8802 cx24123 dvb_pll video_buf_dvb cx88xx i2c_algo_bit video_buf btcx_risc tveeprom videodev cx2341x dvb_core budget_ci budget_core tda1004x dvb_ttpci saa7146_vv stv0299 ves1820 tda8083 sp8870 ves1x93 dvb_core video_buf saa7146 ttpci_eeprom l64781 stv0297 v4l1_compat v4l2_common videodev cx8800 cx88xx i2c_algo_bit tveeprom videodev v4l2_common v4l1_compat video_buf btcx_risc compat_ioctl32 v4l2_common ir_common lnbp21 tuner v4l2_common cx24116 isl6421 cx88-dvb eeprom tea5767 tda8290 tuner_simple mt20xx videobuf_dvb dvb_core videobuf_dma_sg videobuf_core tda18271 tda827x tuner_xc2028 tda9887 I got : saa7146: unregister extension 'budget_ci dvb'. Unable to handle kernel paging request at 00100100 RIP: [8045cf5c] evdev_disconnect+0xac/0xe0 PGD 16fbe2067 PUD 16d0e9067 PMD 0 Oops: [1] PREEMPT SMP CPU 0 Modules linked in: nfs lockd sunrpc ipv6 coretemp w83627ehf w83791d hwmon_vid hwmon eeprom isl6421 cx24116 stv0299 tuner firewire_ohci firewire_core cx8800 budget_ci budget_core nvidia(P) cx88xx crc_itu_t dvb_core i2c_algo_bit saa7146 ttpci_eeprom ir_common ohci1394 ieee1394 snd_hda_intel compat_ioctl32 tveeprom videodev v4l2_common v4l1_compat video_buf btcx_risc i2c_i801 button sky2 usb_storage Pid: 7881, comm: rmmod Tainted: P2.6.23 #1 RIP: 0010:[8045cf5c] [8045cf5c] evdev_disconnect+0xac/0xe0 RSP: 0018:81016d895d38 EFLAGS: 00010216 RAX: RBX: 000ffae8 RCX: RDX: RSI: 81016d65ee40 RDI: 81000642ae00 RBP: 81017e8c5888 R08: 81016d894000 R09: 810006428de8 R10: 0002 R11: 8052d640 R12: 81017e8c5800 R13: 81017e8c5898 R14: 81017dd1f000 R15: 7fffc92da880 FS: 2b3ce17fdb00() GS:8065() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00100100 CR3: 00016fbe CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process rmmod (pid: 7881, threadinfo 81016d894000, task 81016d65ee40) Stack: 7fffc92da880 81017dffa8f8 81017dffa000 81017dffa920 81017dd1f000 8045a97d 81017dd1f07c 81017dd28000 81017dffa000 8898c36f 0003 81017fcf40f8 Call Trace: [8045a97d] input_unregister_device+0x8d/0x130 [8898c36f] :budget_ci:budget_ci_detach+0x13f/0x1f0 [880cc19f] :saa7146:saa7146_remove_one+0x8f/0x170 [803a243c] pci_device_remove+0x2c/0x60 [803fdec2] __device_release_driver+0x82/0xc0 [803fe4c6] driver_detach+0xe6/0xf0 [803fd921] bus_remove_driver+0x81/0xb0 [803a263e] pci_unregister_driver+0x1e/0x80 [880cbd54] :saa7146:saa7146_unregister_extension+0x54/0x60 [8025b2d5] sys_delete_module+0x165/0x1f0 [8038fbe2] __up_write+0x22/0x130 [8020bd8e] system_call+0x7e/0x83 Code: 48 8b 83 18 06 00 00 0f 18 08 48 8d 83 18 06 00 00 48 39 e8 RIP [8045cf5c] evdev_disconnect+0xac/0xe0 RSP 81016d895d38 CR2: 00100100 which I habe no clue on how to debug ??? Does anyone got an idea ? Thank you very much :-) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] System fails to boot on adding second DVB-T PCI card
Hi, On Thu, Jan 10, 2008 at 02:03:55AM +0100, hermann pitton wrote: Am Donnerstag, den 10.01.2008, 01:13 +0200 schrieb Axel Thimm: On Wed, Jan 09, 2008 at 11:42:19PM +0100, hermann pitton wrote: video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) video_buf: exports duplicate symbol videobuf_mmap_mapper (owned by videobuf_core) Guess this is the root of the problem. Axel's modules might fail to eliminate it. Mauro has converted the old single videobuf.ko to different types to be more flexible. Looks like you have an upgrade to the new types without that the old videobuf.ko is removed from your /lib/modules.../media stuff. Try to remove/delete it manually and depmod -a. is there a way to somehow blacklist videobuf.ko w/o having to remove it? The reason is that packagewise this belongs to the kernel rpm which is managed by the upstream vendor (e.g. Red Hat, Fedora) and I wouldn't want to nuke it - it would return anyway with the next kernel update. Instead maybe some dummy alias or some remapping could be made to effectively remove it from module-utils' radar w/o actually removing the file? That would be much cleaner from a packaging POV. Thanks! here it is de facto gone, if not anymore in the next kernel release. What you do in between is up to you. If you like to stay in sync as close as possible, of course v4l-dvb counts and not the delayed kernel stuff. Yes, I understand that - but I'm interested in providing recent v4l/dvb for users of for example 2.6.18 kernels as well, as found in RHEL5/CentOS5/SL5. This allows users or even OEMs to build multimedia systems on stable enterprise platforms. It all works quite well as there are mechanisms to override the kernel's modules - only when they are renamed like in this case one needs to take special care. That was what I was asking about. :) -- Axel.Thimm at ATrpms.net pgplfezMzEPe9.pgp Description: PGP signature ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Dazzle Tv Mobile and Secam issue
Hello. I have dazzle tv mobile wich is detected by system as Pinnacle PCTV USB2 I installed latest dvb drivers, but via mplayer and kdetv picture from tv input with choosing norm(secam) picture is being bw. However, Composite1 input in PAL works fine. I have OpenSUSE 10.3 with 2.6.22-13 0.3 kernel My tv file: alias char-major-81 videodev options em28xx card=3 i2c_scan=1 tuner=38 options i2c-algo-bit bit_test=1 alias char-major-81-0 off alias char-major-81-1 em28xx alias char-major-81-2 off alias char-major-81-3 off My dmesg skyline1:/etc/sysconfig # dmesg | grep em28xx em28xx v4l2 driver version 0.1.0 loaded em28xx new video device (2304:0208): interface 0, class 255 em28xx Has usb audio class em28xx #0: Alternate settings: 8 em28xx #0: Alternate setting 0, max size= 0 em28xx #0: Alternate setting 1, max size= 1024 em28xx #0: Alternate setting 2, max size= 1448 em28xx #0: Alternate setting 3, max size= 2048 em28xx #0: Alternate setting 4, max size= 2304 em28xx #0: Alternate setting 5, max size= 2580 em28xx #0: Alternate setting 6, max size= 2892 em28xx #0: Alternate setting 7, max size= 3072 em28xx #0: em28xx chip ID = 18 em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 08 02 10 00 1e 03 98 1e 6a 2e em28xx #0: i2c eeprom 10: 00 00 06 57 6e 00 00 00 8e 00 00 00 07 00 00 00 em28xx #0: i2c eeprom 20: 16 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 2e 03 50 00 69 00 em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 20 00 47 00 em28xx #0: i2c eeprom 90: 6d 00 62 00 48 00 00 00 1e 03 50 00 43 00 54 00 em28xx #0: i2c eeprom a0: 56 00 20 00 55 00 53 00 42 00 32 00 20 00 50 00 em28xx #0: i2c eeprom b0: 41 00 4c 00 00 00 06 03 31 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 0e 5d 62 35 03 ad 8f 26 em28xx #0: found i2c device @ 0x4a [saa7113h] em28xx #0: found i2c device @ 0x86 [tda9887] em28xx #0: found i2c device @ 0x8e [remote IR sensor] em28xx #0: found i2c device @ 0xa0 [eeprom] em28xx #0: found i2c device @ 0xc6 [tuner (analog)] saa7115' 1-0025: saa7113 found (1f7113d0e10) @ 0x4a (em28xx #0) tuner' 1-0043: chip found @ 0x86 (em28xx #0) tuner' 1-0063: chip found @ 0xc6 (em28xx #0) em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 em28xx #0: Found Pinnacle PCTV USB 2 em28xx audio device (2304:0208): interface 1, class 1 em28xx audio device (2304:0208): interface 2, class 1 usbcore: registered new interface driver em28xx options tuner secam=d makes nothing ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Dazzle Tv Mobile and Secam issue
Hi, As this is an analogue TV related issue, you should post to the v4l mailing list instead ... dvb is for digital tv, and it doesn't appear that your device supports such anyway. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Proposal] Regarding the mailing lists
Michel Lespinasse wrote: On Thu, Jan 10, 2008 at 06:33:13PM -0500, CityK wrote: - merge/consolidate the [linux-dvb] and [video4linux-list] into one [LinuxTV-users] list - that a separate, but totally open and transparent, [LinuxTV-devel] list be created for the express purpose of housing v4l and dvb subsystem development discussions ... The dvb/v4l merging seems to be a good idea. WRT the user/devel split, I think you need to make clear where bug reports need to go. Agreed My instinct would tell me to send them to the devel list, but I would not be 100% sure. To me, I'd say let everything initially fall on the user list --- as it is most traffic on the lists is end users reporting problems ... on a preliminary basis, separating out what is a bona fide bug and what isn't would be too difficult to distinguish ... perhaps some sort of method of evaluating an end user problem report and then elevating it onto the devel list as a bug if it is so determined to be such? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Proposal] Regarding the mailing lists
Hans Verkuil wrote: One factor that perhaps adds some weight to this argument/proposal is the diminishing importance that analogue TV related issues are going to hold over time ( as more and more countries switch to digital transmission systems). Of course, the light won't go out for analogue TV for a number of years to come, but I think that users familiar to the lists will have already noticed the trend towards dvb related topics on the v4l list. v4l is not about analog TV in particular, it is basically for everything video related that is not a DVB device or a graphics card. This includes webcams, MPEG encoders/decoders, digital video streaming, among others. True enough! While analog TV will diminish in importance (in some parts of the world) that does not mean that v4l will become less important. hehe...I think we are in complete agreement on that one -- see the amendment I made earlier in the day to this article: http://www.linuxtv.org/v4lwiki/index.php/Development:_Discussion_of_Video4Linux_API_Version_3 I disagree. As stated above, v4l really deals with video streams in one way or another. Analog TV is a fairly small part of that. So I personally think that v4l is a pretty good descriptor of this subsystem. (Although there are some oddities like radio and RDS devices). To keep in sync with v4l-dvb-maintainer I would suggest v4l-dvb-users and v4l-dvb-devel. Fair enough (i.e. disagreeing about whether v4l is a good descriptor). But a large point here (for me) is in terms of the branding (i.e. LinuxTV) and a move away from the specific subsystem names which, as we apparently both have agreed upon, are not as clear to the end user. In other words, while v4l-dvb-users and v4l-dvb-devel are good, I think we could do better and capitalise on on the LinuxTV branding with what I suggested earlier. - turning to the #irc channels, the same arguments hold, except that the dvb related channel isn't even named as such...rather it carries the linuxtv name ... now, I know that the channel topic headers will describe the type of discussion related to that channel, but honestly, next to no one heeds any attention to that...so it is of my opinion that the situation is even less then clear for the end userin my opinion, its time to make a single channel function for all end users if so desired even two channels -- #LinuxTV-users (or even just usurp the existing #linuxtv channel into becoming multifunctional) and possibly another for developers if they so desire (i.e. #LinuxTV-dvel) Well, I'd choose #v4l-dvb, but otherwise I agree. same response as immediately above I never really think of this as a 'linuxtv' project because I always thought of it as v4l and dvb subsystems and linuxtv being just the domain name. Fair enough, I can see that point. I do, however, as I have argued, believe that the LinuxTV name is superior in terms of description and branding *. * And by branding, if it isn't obvious, I don't mean to imply that we are trying to sell something, but rather am referring strictly to informational clarity. Regards, Hans Thanks for the feedback ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] BUG in videobuf-core.c:73 (MAGIC_CHECK mismatch)
Dear DVB developers, after switching to current http://linuxtv.org/hg/v4l-dvb (2008-01-11 01:03 CET) on an openSUSE 10.2 based vdr system, I harvest these reproducible crashes on trying to record something: Jan 11 01:25:47 ziggy vdr: [3874] switching device 2 to channel 22 Jan 11 01:25:47 ziggy vdr: [3874] timer 12 (22 0055-0140 'Domian unterwegs') start Jan 11 01:25:47 ziggy vdr: [3874] Title: 'Domian unterwegs' Subtitle: '(null)' Jan 11 01:25:47 ziggy vdr: [3874] record /video0/Domian_unterwegs/2008-01-11.00.55.99.99.rec Jan 11 01:25:47 ziggy vdr: [3874] cFileName::SetOffset: removing zero-sized file /video0/Domian_unterwegs/2008-01-11.00.55.99.99.rec/001.vdr Jan 11 01:25:47 ziggy vdr: [3874] recording to '/video0/Domian_unterwegs/2008-01-11.00.55.99.99.rec/001.vdr' Jan 11 01:25:47 ziggy vdr: [4053] file writer thread started (pid=3874, tid=4053) Jan 11 01:25:47 ziggy vdr: [4054] recording thread started (pid=3874, tid=4054) Jan 11 01:25:47 ziggy vdr: [4055] receiver on device 2 thread started (pid=3874, tid=4055) Jan 11 01:25:47 ziggy vdr: [4056] TS buffer on device 2 thread started (pid=3874, tid=4056) Jan 11 01:25:47 ziggy kernel: Error: mmap_mapper() never called! Jan 11 01:25:47 ziggy kernel: magic mismatch: f6941bc0 (expected 20070728) Jan 11 01:25:47 ziggy kernel: [ cut here ] Jan 11 01:25:47 ziggy kernel: kernel BUG at /usr/src/kernel-modules/v4l-dvb/v4l/videobuf-core.c:73! Jan 11 01:25:47 ziggy kernel: invalid opcode: [#1] SMP Jan 11 01:25:47 ziggy kernel: last sysfs file: /devices/pci:00/:00:18.3/temp3_input Jan 11 01:25:47 ziggy kernel: Modules linked in: nfsd auth_rpcgss exportfs ipv6 autofs4 snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfs lock d nfs_acl sunrpc af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 zl10353 xc5000 ves1820 tua6100 tda827x tda826x td a8083 tda18271 tda10086 tda1004x tda10023 tda10021 stv0297 sp887x sp8870 s5h1420 s5h1409 qt1010 or51211 or51132 nxt6000 nxt200x mt352 mt312 mt226 6 mt2131 mt2060 lnbp21 lgdt330x l64781 dvb_pll dib7000p dib7000m dib3000mc dibx000_common dib3000mb dib0070 cx24110 cx22702 cx22700 bcm3510 stv02 99 ves1x93 dvb_ttpci button battery ac power_supply nls_utf8 ntfs loop isl6421 cx24123 cx88_dvb cx88_vp3054_i2c videobuf_dvb cx88_alsa snd_pcm sn d_timer snd soundcore rtc_cmos snd_page_alloc cx8800 rtc_core cx8802 cx88xx dvb_core rtc_lib firmware_class ir_common saa7146_vv i2c_algo_bit k8t emp saa7146 compat_ioctl32 tveeprom videobuf_dma_sg videodev hwmon videobuf_core v4l2_common v4l1_compat btcx_risc ttpci_eeprom ohci1394 ieee1394 forcedeth Jan 11 01:25:47 ziggy kernel: ide_cd cdrom ohci_hcd ehci_hcd usbcore i2c_nforce2 i2c_core parport_pc lp parport xfs edd sg fan sata_nv libata amd 74xx thermal processor sd_mod scsi_mod ide_disk ide_core Jan 11 01:25:47 ziggy kernel: Jan 11 01:25:47 ziggy kernel: Pid: 4052, comm: cx88[0] dvb Tainted: G N (2.6.24-rc7-20080109173439-default #1) Jan 11 01:25:47 ziggy kernel: EIP: 0060:[f91e4608] EFLAGS: 00010282 CPU: 0 Jan 11 01:25:47 ziggy kernel: EIP is at videobuf_waiton+0x4d/0xe9 [videobuf_core] Jan 11 01:25:47 ziggy kernel: EAX: 0030 EBX: dfc2b1ac ECX: 0046 EDX: 0046 Jan 11 01:25:47 ziggy kernel: ESI: EDI: f6961fb0 EBP: 0001 ESP: f6961f90 Jan 11 01:25:47 ziggy kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Jan 11 01:25:47 ziggy kernel: Process cx88[0] dvb (pid: 4052, ti=f696 task=f69626f0 task.ti=f696) Jan 11 01:25:47 ziggy kernel: Stack: f91e580a f6941bc0 20070728 f69626f0 c0120107 Jan 11 01:25:47 ziggy kernel:dfc2b1d0 dfc2b110 dfc2b1ac f9307361 dfc2b110 dfc2b110 Jan 11 01:25:47 ziggy kernel:f93072fb c01361b1 c0136179 c0106307 f7125de0 Jan 11 01:25:47 ziggy kernel: Call Trace: Jan 11 01:25:47 ziggy kernel: [f9307361] videobuf_dvb_thread+0x66/0x131 [videobuf_dvb] Jan 11 01:25:47 ziggy kernel: [c01361b1] kthread+0x38/0x5d Jan 11 01:25:47 ziggy kernel: [c0106307] kernel_thread_helper+0x7/0x10 Jan 11 01:25:47 ziggy kernel: === Jan 11 01:25:47 ziggy kernel: Code: a1 00 10 45 c0 89 44 24 10 8b 43 04 3d 28 07 07 20 74 1c c7 44 24 08 28 07 07 20 89 44 24 04 c7 04 24 0a 58 1 e f9 e8 b1 f4 0f c7 0f 0b eb fe 8d 43 34 8d 54 24 0c e8 8b 1f f5 c6 eb 67 85 f6 74 Jan 11 01:25:47 ziggy kernel: EIP: [f91e4608] videobuf_waiton+0x4d/0xe9 [videobuf_core] SS:ESP 0068:f6961f90 Jan 11 01:25:47 ziggy kernel: ---[ end trace 89f8cead76ef35ad ]--- Jan 11 01:25:48 ziggy vdr: [3959] channel 22 (EinsFestival) event Fre 11.01.2008 01:00-01:30 (VPS: 11.01 00:59) 'Domian unterwegs' status 4 Jan 11 01:25:51 ziggy vdr: [3874] connect from 127.0.0.2, port 42097 - accepted Jan 11 01:25:51 ziggy vdr: [3876] video directory scanner thread ended (pid=3874, tid=3876) Jan 11 01:25:52 ziggy vdr: [3874] closing SVDRP connection Jan 11 01:25:56 ziggy vdr: [3961] frontend 1 timed out while
[linux-dvb] [PATCH] Fix the compilation of the bttv driver, when advanced debugging is not enabled
Well, not much to say :) --- Fix the compilation of the bttv driver, when advanced debugging is not enabled. Signed-off-by: Zoltan Devai [EMAIL PROTECTED] --- a/drivers/media/video/bt8xx/bttv-driver.c 2008-01-10 11:33:03.0 +0100 +++ b/drivers/media/video/bt8xx/bttv-driver.c 2008-01-11 02:07:53.0 +0100 @@ -3445,8 +3445,10 @@ .vidioc_s_frequency = bttv_s_frequency, .vidioc_log_status = bttv_log_status, .vidioc_querystd= bttv_querystd, +#ifdef CONFIG_VIDEO_ADV_DEBUG .vidioc_g_register = bttv_g_register, .vidioc_s_register = bttv_s_register, +#endif .tvnorms= BTTV_NORMS, .current_norm = V4L2_STD_PAL, }; ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] dvb-fe-nxt2004.fw not available any more?
Hi, I just tried to get dvb-fe-nxt2004.fw using perl get_dvb_firmware nxt2004 But it seems that the firmware is not there any more. Aver move it to another place, why we copy as much firmware as possible into linuxtv's website, then the perl script will not be any problem? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
