[linux-dvb] DiB0700 firmware problems
Hi all, it seems that there still problems related to USB with the latest firmware. In order to figure out what is the problem I would like to gather some information about the affected systems: Can everyone (people who still have the disconnects and the ones who don't) please reply directly to this email giving the following information: 1) system (uname -a) 2) lspci-output 3) DiB0700 device name (USB Stick, Nova-T 500) 4) Application using the device (MythTV, VDR etc) 5) Symptoms (unusable, disconnect after x days, no problem) Please make sure that you are using the latest firmware (version 1.10) . thanks and regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Strange DVB-T using scan and tzap FEC and Guard interval problems
Hi, Our DVB-T network has once more been changed here in Karlstad, Sweden. Once more I noticed strange behaviour with scan (atrpms linuxtv-dvb-apps ver 1.1.1.2_20070420.fc7) and tzap. It used to work without a problem before. After creating a scan file with fec high, low and guard interval set to auto I was able to scan a Mux for channels and create a channels.conf. I knew the frequency(650MHz), the bandwidth(8MHz), the modulation (QAM64) and the transmission-mode (8k). However in trying to use the resulting channels.conf with tzap, I never get a lock. I didn't know the FEC or guard interval part. Now I have 2 different types of DVB-T cards. One Nova T 500 PCI Dib0700(Yes I know, I have the latest firmware) and a TerraTec Cinergy 1200 DVB-T (SAA7146) Using my favorite card (the 1200) i tried a frequency search in MythTV using one of the mux frequencies and the other bits I knew. No luck :( Then I tried the same using the Nova T 500. Yes it found and locked to channels ! Anyway to cut a long story even longer ;) ... I read the resulting entries in the mythtv database and edited my channels.conf then tzap worked with both cards ?? scan was saying ... SVT1:65000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1019:1018:1010 when MythTV and tzap needed ... SVT1:65000: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 ie. FEC_2_3 and GUARD_INTERVAL_1_8 were needed for tzap and MythTV using scan again with a few -vvv gave this ... parse_terrestrial_delivery_system_descriptor:498: 0x3184/0x3fd 65000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE ie. the wrong?? FEC and GUARD interval Anybody know whats going on here ?? Is the network sending wrong info ?? Thanks, Simon G. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] video-buf redesign
Hi, Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb [EMAIL PROTECTED]: Mauro Carvalho Chehab wrote: Unfortunately, I see the same broken behavior in the videobuf tree and the tm6000-new tree. Only the master branch v4l-dvb tree is functioning properly. Unfortunately, there's nothing I can do without the logs. So, _please_ send the logs also. Every test I did here (and also Hermann reports) didn't produce the issues you're showing. All I get here is clean mpeg streams, with videobuf-dvb and cx88-dvb. There is, however, a known issue with IRQ and SMP machines that might be influencing. So, I need you to do also cat /proc/cpuinfo. If the machine you're using to test has more than one CPU core, you may also need to run irqbalance. Another valuable test would be to disable the second core, and see what's happening. I also conducted the tests only on UP machines on the saa7134 driver. Mauro, It is a dual-core CPU. This should be irrelevant to the issue, since multi-core CPU's have no problem when using the videobuf code in the master branch -- why would your new videobuf code be dependent on a single core when the original videobuf code was not? I had previously sent you logs of this problem while using read() , but you said this was not good enough -- You told me that the logs did not indicate any errors. The only way to test this without using read() would be to use xawtv4, which I am not able to build on my Ubuntu Feisty system. Otherwise, I could try to test by installing mythtv-backend, but that will take a lot of time to setup -- I'll be happy to do it after I've settled in the new apartment, if need be. I understand that neither you nor Hermann were able to reproduce this problem, but I assure you, this is indeed a regression, and it's a show-stopper for 2.6.24 -- it absolutely must be fixed prior to a merge. Yes, I agree then. We should be careful with this small testing base we have and Mike obviously noticed issues. I will not be able to conduct any more tests until after I unpack into my new apartment (next week) -- I will take down this test machine tonight and pack it up in boxes. If you still would like to see logs while using read() , then I can do this tonight before I pack up the test machine. If you want these logs, please let me know asap. Unfortunately I have not even a DVB-T card currently ... The Medion Quad I ordered isn't here yet, also unsure if I can get DVB-T running on it, don't have the original green PCI Slot for it. Else I considered to get the Asus P7131 Hybrid LNA, since Soeren still reports issues on it, also memory corruption with the old stuff. http://linuxtv.org/pipermail/linux-dvb/2007-September/020748.html This is still the only such report within the last two years. The only case I know from Hartmut that this could happen, also tested myself, is if someone uses DVB-T and anlog video at once from external inputs with planar formats, like mplayer/mencoder does by default and not packed formats as advised in such case. Why this happens on his machine with VDR and an additional saa7146 device, I still don't know. We have also no reports for the new video_buf design from saa7146 users. Just installed the tm6000-new tree on two machines again and xawtv4 seems to be fine on both, UP, no DVB-T currently, no HD streams. Cheers, Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] video-buf redesign
Em Qua, 2007-09-26 às 22:58 +0200, hermann pitton escreveu: Hi, Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb [EMAIL PROTECTED]: Mauro Carvalho Chehab wrote: Unfortunately, I see the same broken behavior in the videobuf tree and the tm6000-new tree. Only the master branch v4l-dvb tree is functioning properly. Unfortunately, there's nothing I can do without the logs. So, _please_ send the logs also. Every test I did here (and also Hermann reports) didn't produce the issues you're showing. All I get here is clean mpeg streams, with videobuf-dvb and cx88-dvb. There is, however, a known issue with IRQ and SMP machines that might be influencing. So, I need you to do also cat /proc/cpuinfo. If the machine you're using to test has more than one CPU core, you may also need to run irqbalance. Another valuable test would be to disable the second core, and see what's happening. I also conducted the tests only on UP machines on the saa7134 driver. My tests with cx88-dvb were with dualcore AMD. I noticed some logs, indicating that irq handling is not fast enough to handle one irq for every frame buffer. Yet, my machine were capable of not losing any frames (this happened on both the current videobuf and the newer one). Probably, if my machine were a little slow, or if the irq where shared with some other devices, I would lose frames. I'll re-run the tests disabling the second CPU and with both running, but without irqbalance. Let's see. I understand that neither you nor Hermann were able to reproduce this problem, but I assure you, this is indeed a regression, and it's a show-stopper for 2.6.24 -- it absolutely must be fixed prior to a merge. Yes, I agree then. We should be careful with this small testing base we have and Mike obviously noticed issues. Fixing is important. Why this happens on his machine with VDR and an additional saa7146 device, I still don't know. We have also no reports for the new video_buf design from saa7146 users. It may be due to IRQ sharing. If you have two boards receiving interrupts at the same IRQ line, you may suffer this kind of troubles, since both drivers will be called, on a serial way, to handle that IRQ line. This will delay videobuf handling. In this case, a small time increment at videobuf processing may produce such troubles. I'm writing a small patch that will reduce a little bit the videobuf timings. Hopefully, this will fix the issue. Just installed the tm6000-new tree on two machines again and xawtv4 seems to be fine on both, UP, no DVB-T currently, no HD streams. Thanks, Hermann. Cheers, Hermann -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] AF901x
En Mon, 24 Sep 2007 20:00:18 +0200, Jussi Larjo [EMAIL PROTECTED] escribió: Manu others, I have Pinnacle Dazzle 71e with AF9015, but I have no idea about the tuner. The tuner chip is covered with a sticky label that is hard to remove. I can compile and install the driver with no errors, but nothing seems to happen, DVB devices are not generated. I also have a Pinnacle Dazzle 71e. What driver do I have to compile? -- Pepe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB0700 firmware problems
Dne st 26. září 2007 Patrick Boettcher napsal(a): Hi all, Hi Patrick, it seems that there still problems related to USB with the latest firmware. In order to figure out what is the problem I would like to gather some information about the affected systems: Can everyone (people who still have the disconnects and the ones who don't) please reply directly to this email giving the following information: 1) system (uname -a) 2.6.22.5, i386, Pentium M, intel USB 2.0 uhci/ehci 2) lspci-output 3) DiB0700 device name (USB Stick, Nova-T 500) Leadtek WinFast DTV Dongle 4) Application using the device (MythTV, VDR etc) kaffeine 5) Symptoms (unusable, disconnect after x days, no problem) With latest svn snapshoot and 1.10 firmware during sw suspend to disk I see tons of key pressed (but it is not true, keypad doesn't return any keypresses in normal state and I press nothing) and it won't suspend. With same kernel patch and pre3 firmware I see same messages, but it suspends and resume well. Irda doesn't work for me - no numbers returns to terminal pressing 1-9 etc, but let blinks on the dongle, so possibly it recognizes somethink. Kaffeine application is always killed/closed before suspending. Please make sure that you are using the latest firmware (version 1.10) . Yes I am, but without suspend it is not usable for me. thanks and regards, Patrick. See ya! Hope this will help! Michal -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
