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] Satelco EasyWatch + Cryptoworks
On Sat, Feb 02, 2008 at 09:22:22PM +0100, Christoph Pfister wrote: while gnutv reported this (and no stream was present at dvr0): You can run gnutv -out dvr or gnutv -out file filename. These are the outcomes of my latest experiments with the various tuning utilities. All tests refer to the tuning of JSTV1 (Cryptoworks). - gnutv, zap: Most of the time unable to lock in the encrypted channel. The status line keeps udating and displays data similar to these: status SC| signal c080 | snr aa88 | ber ff20 | unc | In this situation, no stream is available on dvr0, or written to a file. However, once in a while, launching these utilities results in correct locking of the channel. In this case the status line gets displayed only once (no update), as in status SCVYL | signal c440 | snr d119 | ber 0900 | unc | FE_HAS_LOCK and is shortly followed by the Received new PMT - sending to CAM... message. In this case, decryption is OK. - szap: always succeeds in locking the channel (but of course, no decryption): status 1f | signal c586 | snr d0f5 | ber | unc | FE_HAS_LOCK Does the snr play any role in the inability of zap/gnutv to tune che channel in? (To my unexperienced eye, all FE_HAS_LOCKs seem to occur only when snr is above a certain threshold.) Do the tuning mechanisms in gnutv/zap and szap differ somehow? Thanks to anyone willing to shed some light on this. David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Satelco EasyWatch + Cryptoworks
Hi, following the suggestion by Manu, I ditched the Twinhan VP1032 (which had problems with the Cryptoworks CAM) and bought a SAA7146-based Satelco EasyWatch PCI card with CI module. This gets recognized as device 1131/7146 subsystem 1894/001b and appears to work with the budget_av + dvb_pll + stv0299 module combination from a vanilla 2.6.24 kernel. Reception of FTA channels is OK, but the CI section looks even more problematic than the VP1032's. The kernel logs dvb_ca adapter 0: DVB CAM detected and initialised successfully However, any attempt to access the CAM fails: [EMAIL PROTECTED]:~$ dst_test -c main: Capabilities APP: Slots=[1] APP: Type=[2] APP: Descrambler keys=[0] APP: Type=[0] [EMAIL PROTECTED]:~$ dst_test -i main: Info No CI Slots found [EMAIL PROTECTED]:~$ dst_test -a main: App Info dst_comms: Msg=[9f 80 30 ] dst_comms: ioctl failed .. dst_get_app_info: Dst communication failed Maybe I'm missing something obvious? Thanks, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 76115215 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] VP1032 + Cryptoworks
On Thu, Jan 03, 2008 at 12:16:22AM +0400, Manu Abraham wrote: Any chance of a fix in the near future? Alternatively, could you suggest another CI card with a less problematic driver? Nothing immediate is expected. It will take time to diagnose what the problem is itself. If you need to look at another card, something based on the SAA7146 might work out. I found in the Wiki that the Satelco EasyWatch PCI and the Technotrend S-1500 both appear to be SAA7146-based. Both have an external CI expansion (with the Satelco bundle being more expensive than the TT one). Can anybody report a success (or failure...) story with any of them? Thanks, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] VP1032 + Cryptoworks
On Thu, Dec 27, 2007 at 12:46:38AM +0400, Manu Abraham wrote: David Santinoli wrote: On Wed, Dec 19, 2007 at 11:49:42PM +0400, Manu Abraham wrote: en50221_app_ai_parse_app_info: Received short data This requires quite a bit as to what messages are sent to the driver. Also possible is a bug in the driver, which can't be ruled out either. Is there any other relevant info I can post to the list to help debugging? I could even allow root access to the machine in question. Do you think the CAM could be ruled out, or should I try a Philips Cryptoworks module instead of the SCM one? I don't think it's an issue with the CAM. Looks like a bug on second thoughts :-( Any chance of a fix in the near future? Alternatively, could you suggest another CI card with a less problematic driver? Many thanks, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] VP1032 + Cryptoworks
On Wed, Dec 19, 2007 at 11:49:42PM +0400, Manu Abraham wrote: en50221_app_ai_parse_app_info: Received short data I think, it could be that the stack at some point sends some junk to the device, thereby causing the device to go crazy. Please do not that the library is divided into 2 parts , the High Level and the Low Level API's . In this case the Low level API part in the library might be sending junk, thereby causing the breakage, also it could be the hardware, but something like a few minutes doesn't seem to be a hardware issue. This requires quite a bit as to what messages are sent to the driver. Also possible is a bug in the driver, which can't be ruled out either. Is there any other relevant info I can post to the list to help debugging? I could even allow root access to the machine in question. Do you think the CAM could be ruled out, or should I try a Philips Cryptoworks module instead of the SCM one? Thanks, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 76115215 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] VP1032 + Cryptoworks
On Wed, Dec 19, 2007 at 02:24:41AM +0400, Manu Abraham wrote: David Santinoli wrote: I've got a VP1032 CI card (PCI id 1822:0001), a Cryptoworks module by SCM, and a regular JSTV (Japanese satellite TV) subscription, but after 5 minutes or so decryption stops working with a Received short data from the tuner app. Is it a known issue of this card and/or module? After getting this message, what does the app_info option of dst test say ? Here's the timeline: [EMAIL PROTECTED]:~$ zap -channels ~/.szap/channels.conf 'JSTV1' Using frontend DST DVB-S, type DVB-S CAM Application type: 01 CAM Application manufacturer: d000 CAM Manufacturer code: CAM Menu string: CryptoWorks CAM supports the following ca system ids: Problem retrieving frontend information: Operation not supported status SCVYL | signal 3000 | snr 168d | ber | unc | FE_HAS_LOCK Received new PMT - sending to CAM... [descrambling works OK for a few minutes, then breaks, and this message appears:] en50221_app_ai_parse_app_info: Received short data [same message repeated ~20 times, then:] CAM Application type: 01 CAM Application manufacturer: d000 CAM Manufacturer code: CAM Menu string: CryptoWorks CAM supports the following ca system ids: If I issue dst_test -a at this point, the result is main: App Info dst_comms: Msg=[9f 80 30 ] dst_comms: Msg=[9f 80 31 ] dst_get_app_info: CI Module Application Info == dst_get_app_info: Application Type=[1], Application Vendor=[3329], Vendor Code=[41727] dst_get_app_info: Application info=[] dst_get_app_info: == [the 'ΓΏ' character is 0xff] Issuing the same command while decryption was working would give the same result. Thanks, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 76115215 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] VP1032 + Cryptoworks
Any suggestions for a DVB-S card supporting Cryptoworks via CAM? I've got a VP1032 CI card (PCI id 1822:0001), a Cryptoworks module by SCM, and a regular JSTV (Japanese satellite TV) subscription, but after 5 minutes or so decryption stops working with a Received short data from the tuner app. Is it a known issue of this card and/or module? I'm currently running the latest kernel and DVB tree. Thanks, David ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] OT: Re: linuxtv.org fell in the blacklists trap
On Thu, Nov 01, 2007 at 11:41:02AM +0100, Benny Amorsen wrote: Many dynamic addresses listed by by SORBS are in fact statically assigned. In SORBS-terminology, dynamic means owner of address does not control reverse DNS for address. This has more to do with that particular list's policy (and credibility) than with the general principle that mail from truly dynamic pools is going to heavily affect your SNR. Feel free to drop mail from SORBS-listed addresses. If I catch a company using SORBS for blacklisting, they get crossed off my list of suppliers. As far as I'm concerned, SORBS is blackmail, not blacklist. If my server got listed for the reason above I'd rather put my efforts in getting a decent reverse lookup, as this is likely to cause problems well beyond a rejection by SORBS. Cheers, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 45490882 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] OT: Re: linuxtv.org fell in the blacklists trap
On Wed, Oct 31, 2007 at 02:41:12PM +0100, thomas schorpp wrote: David Santinoli wrote: Please get real. While you have all the right to choose to run a mail server on a dynamic IP address, you cannot force your policy on the recipients. yes, we can. and we will. That's exactly what spammers like to do - force their policy on the recipients. and Luca is right, lets blacklist all U.S. :D Sure, and the next step will be 0.0.0.0/0. Lo and behold - no spam any more! The issue is not the absolute amount of spam, but rather the SNR. Blacklisting the U.S. is, on the average, not likely to improve the SNR (although it might, in some situations), while blacklisting dynamic pools definitely will. Cheers, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 45490882 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
