Message ID | 20120519203207.GA48169@triton8.kn-bremen.de |
---|---|
State | New |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <vdr-l@jelal.kn-bremen.de>) id 1SVqLm-0007Sz-1y for vdr@linuxtv.org; Sat, 19 May 2012 22:34:38 +0200 X-tubIT-Incoming-IP: 78.46.108.116 Received: from gelbbaer.kn-bremen.de ([78.46.108.116] helo=smtp.kn-bremen.de) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtp for <vdr@linuxtv.org> id 1SVqLl-0000xz-BH; Sat, 19 May 2012 22:34:05 +0200 Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 88E611E006FA; Sat, 19 May 2012 22:34:04 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q4JKW7Wc048389 for <vdr@linuxtv.org>; Sat, 19 May 2012 22:32:07 +0200 (CEST) (envelope-from vdr-l@triton8.kn-bremen.de) Received: (from vdr-l@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q4JKW7GX048388 for vdr@linuxtv.org; Sat, 19 May 2012 22:32:07 +0200 (CEST) (envelope-from vdr-l) From: Juergen Lock <vdr-l@jelal.kn-bremen.de> Date: Sat, 19 May 2012 22:32:07 +0200 To: vdr@linuxtv.org Message-ID: <20120519203207.GA48169@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.19.202116 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0' X-LSpam-Score: -1.1 (-) X-LSpam-Report: No, score=-1.1 required=5.0 tests=BAYES_00=-1.9, RDNS_NONE=0.793 autolearn=no Subject: [vdr] [PATCH, RFC] STB0899 signal strength (pctv452e, others too?) X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sat, 19 May 2012 20:34:38 -0000 Status: O X-Status: X-Keywords: X-UID: 26267 |
Commit Message
Juergen Lock
May 19, 2012, 8:32 p.m. UTC
Hi! (I guess the forums are not the best place to post this, hence reposted here...) By accident I stumbled across the special case for TT-budget S2-3200 (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using the pctv452e driver have the same issue (which are STB0899 too, issue is the red/yellow/green bars in femon/osd didn't appear) I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's make config menu) to enable the patch below. Optional since I don't know if there are STB0899-based tuners that don't have the problem, does anyone here know? (see log, if vdr logs like vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard") and the bars appear without the patch please let us know, noting pci ids for the cards especially if different from 0x13c2:0x1019 or if it's usb, thanx!) Cheers, Juergen And here comes the patch, also at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
Comments
On 19.05.2012 22:32, Juergen Lock wrote: > Hi! > > (I guess the forums are not the best place to post this, hence > reposted here...) > > By accident I stumbled across the special case for TT-budget S2-3200 > (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using > the pctv452e driver have the same issue (which are STB0899 too, > issue is the red/yellow/green bars in femon/osd didn't appear) > I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's > make config menu) to enable the patch below. Optional since I don't > know if there are STB0899-based tuners that don't have the problem, > does anyone here know? (see log, if vdr logs like > > vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard") > > and the bars appear without the patch please let us know, noting > pci ids for the cards especially if different from 0x13c2:0x1019 > or if it's usb, thanx!) > > Cheers, > Juergen > > And here comes the patch, also at: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain > > --- dvbdevice.c.orig > +++ dvbdevice.c > @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c > switch (subsystemId) { > case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2) > } > +#if 1 > + // XXX This is likely not correct for all cards using stb0899 > + // but pctv452e usb ones seem to be affected too... > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) > + MaxSignal = 670; > +#endif > int s = int(Signal) * 100 / MaxSignal; > if (s> 100) > s = 100; > @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co > switch (subsystemId) { > case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2) > } > +#if 1 > + // XXX This is likely not correct for all cards using stb0899 > + // but pctv452e usb ones seem to be affected too... > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) > + MaxSnr = 200; > +#endif > int a = int(Snr) * 100 / MaxSnr; > int b = 100 - (Unc * 10 + (Ber / 256) * 5); > if (b< 0) Maybe I'm missing something here, but why don't you just add the subsystem id of your card to the switch statements? Klaus
On Sat, May 19, 2012 at 11:57:35PM +0200, Klaus Schmidinger wrote: > On 19.05.2012 22:32, Juergen Lock wrote: > > Hi! > > > > (I guess the forums are not the best place to post this, hence > > reposted here...) > > > > By accident I stumbled across the special case for TT-budget S2-3200 > > (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using > > the pctv452e driver have the same issue (which are STB0899 too, > > issue is the red/yellow/green bars in femon/osd didn't appear) > > I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's > > make config menu) to enable the patch below. Optional since I don't > > know if there are STB0899-based tuners that don't have the problem, > > does anyone here know? (see log, if vdr logs like > > > > vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard") > > > > and the bars appear without the patch please let us know, noting > > pci ids for the cards especially if different from 0x13c2:0x1019 > > or if it's usb, thanx!) > > > > Cheers, > > Juergen > > > > And here comes the patch, also at: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain > > > > --- dvbdevice.c.orig > > +++ dvbdevice.c > > @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c > > switch (subsystemId) { > > case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2) > > } > > +#if 1 > > + // XXX This is likely not correct for all cards using stb0899 > > + // but pctv452e usb ones seem to be affected too... > > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) > > + MaxSignal = 670; > > +#endif > > int s = int(Signal) * 100 / MaxSignal; > > if (s> 100) > > s = 100; > > @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co > > switch (subsystemId) { > > case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2) > > } > > +#if 1 > > + // XXX This is likely not correct for all cards using stb0899 > > + // but pctv452e usb ones seem to be affected too... > > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) > > + MaxSnr = 200; > > +#endif > > int a = int(Snr) * 100 / MaxSnr; > > int b = 100 - (Unc * 10 + (Ber / 256) * 5); > > if (b< 0) > > Maybe I'm missing something here, but why don't you just add the subsystem id of your card > to the switch statements? Heh. Because a) it's usb, b) I'm on FreeBSD which doesn't emulate Linux' /sys/class/dvb nodes and finding out which /dev/dvb node belongs to which usbid isn't as straightforward there, and c) I was wondering if the bug maybe affects all STB0899 frontends not just some. Cheers, Juergen
On 20.05.2012 10:55, Juergen Lock wrote: > On Sat, May 19, 2012 at 11:57:35PM +0200, Klaus Schmidinger wrote: >> On 19.05.2012 22:32, Juergen Lock wrote: >>> Hi! >>> >>> (I guess the forums are not the best place to post this, hence >>> reposted here...) >>> >>> By accident I stumbled across the special case for TT-budget S2-3200 >>> (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using >>> the pctv452e driver have the same issue (which are STB0899 too, >>> issue is the red/yellow/green bars in femon/osd didn't appear) >>> I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's >>> make config menu) to enable the patch below. Optional since I don't >>> know if there are STB0899-based tuners that don't have the problem, >>> does anyone here know? (see log, if vdr logs like >>> >>> vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STB0899 Multistandard") >>> >>> and the bars appear without the patch please let us know, noting >>> pci ids for the cards especially if different from 0x13c2:0x1019 >>> or if it's usb, thanx!) >>> >>> Cheers, >>> Juergen >>> >>> And here comes the patch, also at: >>> >>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain >>> >>> --- dvbdevice.c.orig >>> +++ dvbdevice.c >>> @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c >>> switch (subsystemId) { >>> case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2) >>> } >>> +#if 1 >>> + // XXX This is likely not correct for all cards using stb0899 >>> + // but pctv452e usb ones seem to be affected too... >>> + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) >>> + MaxSignal = 670; >>> +#endif >>> int s = int(Signal) * 100 / MaxSignal; >>> if (s> 100) >>> s = 100; >>> @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co >>> switch (subsystemId) { >>> case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2) >>> } >>> +#if 1 >>> + // XXX This is likely not correct for all cards using stb0899 >>> + // but pctv452e usb ones seem to be affected too... >>> + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) >>> + MaxSnr = 200; >>> +#endif >>> int a = int(Snr) * 100 / MaxSnr; >>> int b = 100 - (Unc * 10 + (Ber / 256) * 5); >>> if (b< 0) >> >> Maybe I'm missing something here, but why don't you just add the subsystem id of your card >> to the switch statements? > > Heh. > > Because a) it's usb, b) I'm on FreeBSD which doesn't emulate Linux' > /sys/class/dvb nodes and finding out which /dev/dvb node belongs > to which usbid isn't as straightforward there, and c) I was wondering > if the bug maybe affects all STB0899 frontends not just some. Ah, I see. Well, maybe if this is common to all STB0899 frontends it could even be fixed in the driver itself ;-) I always thought that the *driver* should provide a normalized interface for getting signal strength and snr. It can't be reasonable that every application has to figure these out by itself. Klaus
On Sun, May 20, 2012 at 2:20 AM, Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote: > Well, maybe if this is common to all STB0899 frontends it could even be > fixed in the driver itself ;-) > I always thought that the *driver* should provide a normalized interface > for getting signal strength and snr. It can't be reasonable that every > application has to figure these out by itself. This subject has come up at least a few times, one of which was in the "The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite" thread. For some reason the conversation/interest/whatever dies down, even with a lot of talk about it. It would be great if it ever got resolved but if it hasn't happened by now, with all the attention it has already received, I don't see Linux ever getting a usable standardized scale/method. Of course that means you also won't get one of the most basic & useful tools, a reliable signal meter.
On 05/20/2012 05:51 PM, VDR User wrote: > This subject has come up at least a few times, one of which was in the > "The right way to interpret the content of SNR, signal strength and > BER from HVR 4000 Lite" thread. For some reason the Apart from the SNR/Signal Strength issue, does the card work for you? I just threw it out again and replaced it with a venerable stv0299 card, because it never reliably locked (it locked maybe every fourth time). This is with good signals, neither the stv0299 nor the stv090x cards have any problems with the signal. My stb0899 card is a technisat skystar hd2. Tom
My card is old mystique model satix dvb-s2 ( KNC1 DVB-S2 Plus , Satelco Easywatch DVB-S2 , TT S2 3200, Technisat DVB-S2 all i think has same problem ). Card is working fine, but i cannot see signal level on femon, and can not use any channel scan program like wirbelsacn ( no signal il locked ). I hoped the problem would be resolved in the latest kernel drivers, but not, at least in yaVDR64 0.4.0 (based on Ubuntu 11.04 Natty Narwhal), with linux-media-dkms. 2012/5/20 Thomas Sailer <sailer@sailer.dynip.lugs.ch> > On 05/20/2012 05:51 PM, VDR User wrote: > > This subject has come up at least a few times, one of which was in the >> "The right way to interpret the content of SNR, signal strength and >> BER from HVR 4000 Lite" thread. For some reason the >> > > Apart from the SNR/Signal Strength issue, does the card work for you? I > just threw it out again and replaced it with a venerable stv0299 card, > because it never reliably locked (it locked maybe every fourth time). This > is with good signals, neither the stv0299 nor the stv090x cards have any > problems with the signal. My stb0899 card is a technisat skystar hd2. > > Tom > > > ______________________________**_________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr<http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr> >
Am 20.05.2012 19:24, schrieb Thomas Sailer: > On 05/20/2012 05:51 PM, VDR User wrote: > >> This subject has come up at least a few times, one of which was in the >> "The right way to interpret the content of SNR, signal strength and >> BER from HVR 4000 Lite" thread. For some reason the > > Apart from the SNR/Signal Strength issue, does the card work for you? > I just threw it out again and replaced it with a venerable stv0299 > card, because it never reliably locked (it locked maybe every fourth > time). This is with good signals, Hi, there is a patch for this problem, which made it into the kernel october 2011 http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=history;f=drivers/media/dvb/frontends/stb0899_algo.c;h=117a56926dcad041316a53f4ea47ed3c7263505f;hb=b8ed9e5b8c34dc9fb1882669e45b21e3d0194881 Joerg > neither the stv0299 nor the stv090x cards have any problems with the > signal. My stb0899 card is a technisat skystar hd2. > > Tom > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
On Sun, May 20, 2012 at 10:24 AM, Thomas Sailer <sailer@sailer.dynip.lugs.ch> wrote: >> This subject has come up at least a few times, one of which was in the >> "The right way to interpret the content of SNR, signal strength and >> BER from HVR 4000 Lite" thread. For some reason the > > Apart from the SNR/Signal Strength issue, does the card work for you? I just > threw it out again and replaced it with a venerable stv0299 card, because it > never reliably locked (it locked maybe every fourth time). This is with good > signals, neither the stv0299 nor the stv090x cards have any problems with > the signal. My stb0899 card is a technisat skystar hd2. I have several cards but not that particular one. I was talking about the subject in general. It really only makes sense that there's a standardized way for all devices to present the info to the user/applications.
I have such a card, Pinnacle PCTV SAT HDTV 452E PRO USB. I'm trying to use it but no luck. I've tried (I use Debian): - linux 3.2 kernel After reboot many errors: May 20 10:08:47 wuwek kernel: [ 63.984760] pctv452e: pctv452e_power_ctrl: 1 May 20 10:08:47 wuwek kernel: [ 63.984763] May 20 10:09:45 wuwek kernel: [ 122.072827] pctv452e: I2C error -121; AA 51 CC 00 01 -> 55 51 CC 00 00. May 20 10:09:46 wuwek kernel: [ 123.332819] pctv452e: I2C error -121; AA 36 CC 00 01 -> 55 36 CC 00 00. after connect/disconnect and try to change channel in VDR: May 20 13:26:43 wuwek kernel: [ 1801.872219] INFO: task khubd:96 blocked for more than 120 seconds. May 20 13:26:43 wuwek kernel: [ 1801.872232] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 20 13:26:43 wuwek kernel: [ 1801.872242] khubd D f79ea9c0 0 96 2 0x00000000 May 20 13:26:43 wuwek kernel: [ 1801.872259] f71e62c0 00000046 0000d234 f79ea9c0 00000000 00000000 c12cb2e4 c14839c0 May 20 13:26:43 wuwek kernel: [ 1801.872283] f71e646c c14839c0 f79ea9c0 f3ef7fcc c12c0e25 f3ef7fd0 c12bff7b f3ef7fd0 May 20 13:26:43 wuwek kernel: [ 1801.872303] 00000001 f71e62c0 c103233e 00100100 00200200 f400d200 f3ef7fcc c105d51d May 20 13:26:43 wuwek kernel: [ 1801.872325] Call Trace: May 20 13:26:43 wuwek kernel: [ 1801.872347] [<c12c0e25>] ? _raw_spin_lock_irq+0x9/0x12 May 20 13:26:43 wuwek kernel: [ 1801.872360] [<c12bff7b>] ? wait_for_common+0xc7/0xd1 May 20 13:26:43 wuwek kernel: [ 1801.872375] [<c103233e>] ? try_to_wake_up+0x155/0x155 May 20 13:26:43 wuwek kernel: [ 1801.872390] [<c105d51d>] ? arch_local_irq_save+0xf/0x14 May 20 13:26:43 wuwek kernel: [ 1801.872403] [<c12c0e03>] ? _raw_spin_lock_irqsave+0x8/0x21 May 20 13:26:43 wuwek kernel: [ 1801.872484] [<f83d0c2a>] ? dvb_unregister_frontend+0x95/0xcb [dvb_core] May 20 13:26:43 wuwek kernel: [ 1801.872498] [<c104d5d0>] ? add_wait_queue+0x30/0x30 May 20 13:26:43 wuwek kernel: [ 1801.872530] [<f835e0a9>] ? dvb_usb_adapter_frontend_exit+0x2b/0x56 [dvb_usb] May 20 13:26:43 wuwek kernel: [ 1801.872560] [<f835d276>] ? dvb_usb_exit+0x26/0x88 [dvb_usb] May 20 13:26:43 wuwek kernel: [ 1801.872597] [<f835d30b>] ? dvb_usb_device_exit+0x33/0x43 [dvb_usb] May 20 13:26:43 wuwek kernel: [ 1801.872663] [<f82518d3>] ? usb_unbind_interface+0x3a/0xe9 [usbcore] May 20 13:26:43 wuwek kernel: [ 1801.872687] [<c11f316a>] ? __device_release_driver+0x5e/0x95 May 20 13:26:43 wuwek kernel: [ 1801.872699] [<c11f31b6>] ? device_release_driver+0x15/0x1e May 20 13:26:43 wuwek kernel: [ 1801.872711] [<c11f2e76>] ? bus_remove_device+0x5f/0x6a May 20 13:26:43 wuwek kernel: [ 1801.872722] [<c11f146d>] ? device_del+0xed/0x130 May 20 13:26:43 wuwek kernel: [ 1801.872768] [<f8250268>] ? usb_disable_device+0x56/0x13c [usbcore] May 20 13:26:43 wuwek kernel: [ 1801.872811] [<f824b1c5>] ? usb_disconnect+0x5f/0xb0 [usbcore] May 20 13:26:43 wuwek kernel: [ 1801.872855] [<f824c463>] ? hub_thread+0x420/0xbd4 [usbcore] May 20 13:26:43 wuwek kernel: [ 1801.872870] [<c102a053>] ? __wake_up_common+0x33/0x5a May 20 13:26:43 wuwek kernel: [ 1801.872881] [<c104d5d0>] ? add_wait_queue+0x30/0x30 May 20 13:26:43 wuwek kernel: [ 1801.872925] [<f824c043>] ? usb_remote_wakeup+0x23/0x23 [usbcore] May 20 13:26:43 wuwek kernel: [ 1801.872936] [<c104d12f>] ? kthread+0x63/0x68 May 20 13:26:43 wuwek kernel: [ 1801.872948] [<c104d0cc>] ? kthread_worker_fn+0x101/0x101 May 20 13:26:43 wuwek kernel: [ 1801.872961] [<c12c5bfe>] ? kernel_thread_helper+0x6/0x10 May 20 13:28:43 wuwek kernel: [ 1921.872145] INFO: task khubd:96 blocked for more than 120 seconds. May 20 13:28:43 wuwek kernel: [ 1921.872159] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 20 13:28:43 wuwek kernel: [ 1921.872169] khubd D f79ea9c0 0 96 2 0x00000000 May 20 13:28:43 wuwek kernel: [ 1921.872185] f71e62c0 00000046 0000d234 f79ea9c0 00000000 00000000 c12cb2e4 c14839c0 May 20 13:28:43 wuwek kernel: [ 1921.872208] f71e646c c14839c0 f79ea9c0 f3ef7fcc c12c0e25 f3ef7fd0 c12bff7b f3ef7fd0 May 20 13:28:43 wuwek kernel: [ 1921.872228] 00000001 f71e62c0 c103233e 00100100 00200200 f400d200 f3ef7fcc c105d51d (...) dvb-usb: could not submit URB no. 0 - get them all back - linux 3.2 kernel with linux-media-dkms from yavdr (while it compile without errors, it doesn't work - seems like modules doesn't fit kernel.) Can you tell mi exactly with what kernel and driver this card work? Marx
--- dvbdevice.c.orig +++ dvbdevice.c @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c switch (subsystemId) { case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200 (DVB-S/DVB-S2) } +#if 1 + // XXX This is likely not correct for all cards using stb0899 + // but pctv452e usb ones seem to be affected too... + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) + MaxSignal = 670; +#endif int s = int(Signal) * 100 / MaxSignal; if (s > 100) s = 100; @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co switch (subsystemId) { case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200 (DVB-S/DVB-S2) } +#if 1 + // XXX This is likely not correct for all cards using stb0899 + // but pctv452e usb ones seem to be affected too... + if (!strcmp(device->DeviceName(), "STB0899 Multistandard")) + MaxSnr = 200; +#endif int a = int(Snr) * 100 / MaxSnr; int b = 100 - (Unc * 10 + (Ber / 256) * 5); if (b < 0)