[linux-dvb] VP1032 + Cryptoworks
abraham.manu at gmail.com
Wed Dec 19 20:49:42 CET 2007
David Santinoli wrote:
> 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:
> santinod at romilda:~$ 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: 0000
> 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 00000000 | unc 00000000 | 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:]
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.
More information about the linux-dvb