Re: ngene CI problems
Hello Oliver,
On Wed, 11 May 2011, Oliver Endriss wrote:
On Monday 07 March 2011 14:50:02 Martin Vidovic wrote:
...
- SEC device generates NULL packets (ad infinitum):
When reading from SEC, NULL packets are read and interleaved with
expected packets. They can be even read with dd(1) when nobody is
writing to SEC and even when CAM is not ready.
...
I reworked the driver to strip those null packets. Please try
http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08
a) Tested without CAM, it works OK.
b) Tested with Viaccess Pocket dTV, there are some problems:
Sometimes filtering works, sometimes it doesn't. This summarises the
observed behaviour:
(1) When I read 188 bytes from SEC, I notice first byte isn't 0x47. So, I
count how many bytes need to be skipped to get to the 0x47 byte. For
illustration, let's say 8 bytes need to be skipped.
(2) Now I do CA_RESET ioctl on matching CA device and wait 3 seconds.
(3) Repeat step (1) but now I count 4 bytes need to be skipped.
(4) Do CA_RESET.
(5) NULL packets can't be read now.
(6) Do CA_RESET.
(7) Repeat step (1) and now 184 bytes need to be skipped.
(8) and so on...
Here is the code I used for testing:
#include stdlib.h
#include unistd.h
#include string.h
#include errno.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include pthread.h
#include linux/dvb/ca.h
#include stdio.h
#define NUM_PKT 672
#define BUF_SIZE (NUM_PKT * 188)
int fd_ca = -1;
int fd_sec = -1;
unsigned char *buf_in = NULL;
pthread_t read_thread;
int err(const char *msg) {
printf(ERROR: %s (%m).\n, msg);
return 1;
}
void *read_thread_main(void *tparm) {
ssize_t n_read = 0;
size_t prev_sync_off = 0;
size_t prev_sync_diff = 0;
size_t i = 0;
while (1) {
n_read = read(fd_sec, buf_in, BUF_SIZE);
if (n_read 0) {
printf([%zd b]: , n_read);
prev_sync_off = 0;
for (i = 1; i n_read; i++) {
if (buf_in[i] == 0x47) {
/* measure distance between two sync
bytes */
if ((i - prev_sync_off) !=
prev_sync_diff) {
prev_sync_diff = (i -
prev_sync_off);
printf(%zu @ %zu; ,
prev_sync_diff, i);
}
prev_sync_off = i;
}
}
printf(\n);
} else if (n_read 0) {
printf(SEC read error '%m'.\n);
break;
}
}
return NULL;
}
int main(int argc, char **argv) {
char path_ca[] = /dev/dvb/0123456789abcdef/ca0;
char path_sec[] = /dev/dvb/0123456789abcdef/sec0;
/* make dev paths + malloc buffers */
if (argc != 2) {
printf(usage: %s adapter_name\n, argv[0]);
return 1;
}
if (strlen(argv[1]) 16)
return err(adapter name too long (max 16));
sprintf(path_ca, /dev/dvb/%s/ca0, argv[1]);
sprintf(path_sec, /dev/dvb/%s/sec0, argv[1]);
buf_in = malloc(BUF_SIZE);
if (buf_in == NULL)
return err(malloc buf_in);
/* open devs */
fd_ca = open(path_ca, O_RDWR);
if (fd_ca == -1)
return err(open path_ca);
fd_sec = open(path_sec, O_RDWR);
if (fd_sec == -1)
return err(open path_sec);
/* start work */
if (pthread_create(read_thread, NULL, read_thread_main, NULL) != 0)
return err(read_thread start failed.);
pthread_detach(read_thread);
/* CA reset loop */
while (1) {
sleep(3);
printf(\nCA reset\n\n);
ioctl(fd_ca, CA_RESET);
}
}
Best regards,
Martin Vidovic
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 11/05/2011 20:59, Oliver Endriss wrote: I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 CU Oliver Great! Will give it a try tonight and report. Thx, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On Thursday 12 May 2011 22:28:52 Issa Gorissen wrote: On 11/05/11 20:59, Oliver Endriss wrote: I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 Tried your patch, but FFs have been replaced by 6Fs in null packets. Other than that, no improvement for me. Please double check that the patch applied cleanly. The 0x6F NULL packets should never be passed to userspace. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On Monday 07 March 2011 14:50:02 Martin Vidovic wrote: ... - SEC device generates NULL packets (ad infinitum): When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready. ... I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ngene CI problems
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Issa Gorissen
Sent: samedi 23 avril 2011 12:20
To: Ralph Metzler
Cc: xtro...@gmail.com; linux-media@vger.kernel.org
Subject: Re: ngene CI problems
On 23/04/11 00:16, Issa Gorissen wrote:
Hi all!
I'm trying to make the DVB_DEVICE_SEC approach work, however I'm
experiencing certain problems with the following setup:
Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/
http://linuxtv.org/hg/%7Eendriss/v4l-dvb/
Hardware:
Digital Devices CineS2 + CI Module
Problems:
- Packets get lost in SEC device:
I write complete TS to SEC, but when reading from SEC there are
discontinuities on the CC.
- SEC device generates NULL packets (ad infinitum):
When reading from SEC, NULL packets are read and interleaved with
expected packets. They can be even read with dd(1) when nobody is
writing to SEC and even when CAM is not ready.
- SEC device blocks on CAM re-insertion:
When CAM is removed from the slot and inserted again, all read()
operations just hang. Rebooting resolves the problem.
- SEC device does not respect O_NONBLOCK:
In connection to the previous problem, SEC device blocks even if
opened with O_NONBLOCK.
Best regards,
Martin Vidovic
Hi,
Running a bunch of test with gnutv and a DuoFLEX S2.
I saw the same problem concerning the decryption with a CAM.
I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also
applied the patch moving from SEC to CAIO.
I would run gnutv like 'gnutv -out stdout channelname
/dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 |
mplayer -'
Mplayer would complain the file is invalid. Simply running simply 'cat
/dev/dvb/adapter0/caio0' will show me the same data pattern over and
over.
Anyone using ngene based card with a CAM running successfully ?
Hi Ralph,
Could you enlighten us on the following matter please ?
I took a look inside cxd2099.c and I found that the method I suspect to
read/write data from/to the CAM are not activated.
These methods dont't seem to be needed, except by the BUFFER_MODE (no doc
about what it is).
Usually, the CA device is only used to dialog with the CAM through 4 specials
functions (x_attribute_mem and x_cam_control)
The TS stream to be decoded and the decoded TS stream don't go through this CA
device but through the SEC device.
The SEC device is associated to one serial TS out pin and one serial in pin of
the Micronas nGene bridge.
The CI device seems to be hardcoded to work at 62mbps, that means you will
always read at 62mbps from SEC and you will not be able to write at more than
62mbps on SEC.
When there is not enough TS packets to decode, the CI device will send padding
TS packets (the one with PID=0x1FFF and full of 0xFF data) to keep the output
bandwidth at 62mbps.
This is my current understanding of this (un)famous CI interface, hope it may
help.
By the way, I wasn't yet able to decode any channel with this card.
Does someone here manage to decode a channel and kind provide a setup?
static struct dvb_ca_en50221 en_templ = {
.read_attribute_mem = read_attribute_mem,
.write_attribute_mem = write_attribute_mem,
.read_cam_control= read_cam_control,
.write_cam_control = write_cam_control,
.slot_reset = slot_reset,
.slot_shutdown = slot_shutdown,
.slot_ts_enable = slot_ts_enable,
.poll_slot_status= poll_slot_status,
#ifdef BUFFER_MODE
.read_data = read_data,
.write_data = write_data,
#endif
};
Methods read_data and write_data are both enclosed inside the
BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does
not provide for read_data/write_data methods, right ?
If I recall right, you once told that you manage to test the CAM
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html,
how did you do ?
Thx
--
Issa
--
To unsubscribe from this list: send the line unsubscribe linux-media
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 00:16, Issa Gorissen wrote:
Hi all!
I'm trying to make the DVB_DEVICE_SEC approach work, however I'm
experiencing certain problems with the following setup:
Software:
Linux 2.6.34.8 (vanilla)
drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/
http://linuxtv.org/hg/%7Eendriss/v4l-dvb/
Hardware:
Digital Devices CineS2 + CI Module
Problems:
- Packets get lost in SEC device:
I write complete TS to SEC, but when reading from SEC there are
discontinuities on the CC.
- SEC device generates NULL packets (ad infinitum):
When reading from SEC, NULL packets are read and interleaved with
expected packets. They can be even read with dd(1) when nobody is
writing to SEC and even when CAM is not ready.
- SEC device blocks on CAM re-insertion:
When CAM is removed from the slot and inserted again, all read()
operations just hang. Rebooting resolves the problem.
- SEC device does not respect O_NONBLOCK:
In connection to the previous problem, SEC device blocks even if opened
with O_NONBLOCK.
Best regards,
Martin Vidovic
Hi,
Running a bunch of test with gnutv and a DuoFLEX S2.
I saw the same problem concerning the decryption with a CAM.
I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also
applied the patch moving from SEC to CAIO.
I would run gnutv like 'gnutv -out stdout channelname
/dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -'
Mplayer would complain the file is invalid. Simply running simply 'cat
/dev/dvb/adapter0/caio0' will show me the same data pattern over and over.
Anyone using ngene based card with a CAM running successfully ?
Hi Ralph,
Could you enlighten us on the following matter please ?
I took a look inside cxd2099.c and I found that the method I suspect to
read/write data from/to the CAM are not activated.
static struct dvb_ca_en50221 en_templ = {
.read_attribute_mem = read_attribute_mem,
.write_attribute_mem = write_attribute_mem,
.read_cam_control= read_cam_control,
.write_cam_control = write_cam_control,
.slot_reset = slot_reset,
.slot_shutdown = slot_shutdown,
.slot_ts_enable = slot_ts_enable,
.poll_slot_status= poll_slot_status,
#ifdef BUFFER_MODE
.read_data = read_data,
.write_data = write_data,
#endif
};
Methods read_data and write_data are both enclosed inside the
BUFFER_MODE test. Also, current version of struct dvb_ca_en50221 does
not provide for read_data/write_data methods, right ?
If I recall right, you once told that you manage to test the CAM
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html,
how did you do ?
Thx
--
Issa
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
Hi Issa, Running a bunch of test with gnutv and a DuoFLEX S2. I have a DuoFlex S2 running with CI, but not nGene based (it's attached to Octopus card - ddbridge module). I would run gnutv like 'gnutv -out stdout channelname /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over. I suspect the problem is that reads/writes are not aligned to 188 bytes with such invocation of commands. Maybe if you tried replacing 'cat' and '' with 'dd' (bs=188). Other important thing seems to be, to read from the caio0 fast enough or real data is overwritten with null packets (haven't proved it, but it looks this way on nGene). Hope this helps. Best regards, Martin Vidovic -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 13:37, Martin Vidovic wrote: Hi Issa, Running a bunch of test with gnutv and a DuoFLEX S2. I have a DuoFlex S2 running with CI, but not nGene based (it's attached to Octopus card - ddbridge module). I would run gnutv like 'gnutv -out stdout channelname /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over. I suspect the problem is that reads/writes are not aligned to 188 bytes with such invocation of commands. Maybe if you tried replacing 'cat' and '' with 'dd' (bs=188). Other important thing seems to be, to read from the caio0 fast enough or real data is overwritten with null packets (haven't proved it, but it looks this way on nGene). Hope this helps. Best regards, Martin Vidovic Okay, but have you managed to decode any channel yet ? I find some code odd, maybe you can take a look as well... init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0. Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
Hi, Okay, but have you managed to decode any channel yet ? Yes, I managed to descramble programmes without any problem. I find some code odd, maybe you can take a look as well... init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0. Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam They don't connect explicitly. Transfers are done implicitly through nGene ring-buffers. See demux_tasklet(). CXD code seems to be used only for CAM commands and setup (only) of data transfers. Unfortunately, I don't have nGene (and CXD) chip documentation, so I stopped solving the problem myself. I don't want to write software by guessing how HW works. Best regards, Martin Vidovic -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 14:39, Martin Vidovic wrote: Hi, Okay, but have you managed to decode any channel yet ? Yes, I managed to descramble programmes without any problem. I find some code odd, maybe you can take a look as well... init_channel in ngene-core.c creates the device sec0/caio0 with the struct ngene_dvbdev_ci. In ngene-dvb.c you can see that this struct declares the methods ts_read/ts_write to handle r/w operations on the device sec0/caio0. Now take a look at those methods (ts_read/ts_write). I don't see how they 'connect' to the file cxd2099.c which contains the methods handling the i/o to the cam They don't connect explicitly. Transfers are done implicitly through nGene ring-buffers. See demux_tasklet(). CXD code seems to be used only for CAM commands and setup (only) of data transfers. I have taken a look into the ddbrigde module code from http://linuxtv.org/hg/~endriss/ngene-octopus-test/rev/6b400d63c481 The ts_read/ts_write methods are different from the ngene module's. So I guess were are having entirely different problems. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote: Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 19:40, Oliver Endriss wrote: On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote: Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On Saturday 23 April 2011 20:56:47 Issa Gorissen wrote: On 23/04/11 19:40, Oliver Endriss wrote: On Saturday 23 April 2011 00:16:56 Issa Gorissen wrote: Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work. Basically you should not have to hack anything. - Setup the CI as with any conventional device. - Write the encrypted stream into sec0. - Read the decrypted stream from sec0. This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.) CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 21:14, Oliver Endriss wrote: If you are running 2.6.39rc4, you must apply patch http://www.mail-archive.com/linux-media@vger.kernel.org/msg29870.html Otherwise the data will be garbled. Oliver, this patch was applied already. I'm hacking the ts_read/ts_write method, but so far, haven't manage to get it work. Basically you should not have to hack anything. - Setup the CI as with any conventional device. - Write the encrypted stream into sec0. - Read the decrypted stream from sec0. This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.) Oliver, Is there a preferred way to do this (read/write from sec0) ? I mean, does a 'gnutv -channels file -out stdout channelname sec0' and 'cat sec0 | mplayer -' should work according to your tests ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene CI problems
On 23/04/11 21:14, Oliver Endriss wrote: Basically you should not have to hack anything. - Setup the CI as with any conventional device. - Write the encrypted stream into sec0. - Read the decrypted stream from sec0. This should work. (Please note that I could do some loopback tests only, as I am not watching paytv.) CU Oliver Oliver, This does not work. I have launch gnutv like this: 'gnutv -adapter 0 -channels hb.conf -out dvr -timeout 30 TF1' Then on dd tv@tv:~ dd if=188 if=/dev/dvb/adapter0/dvr0 of=/dev/dvb/adapter0/caio0 ^C36071+1 records in 36071+0 records out 18468352 bytes (18 MB) copied, 76.4947 s, 241 kB/s And another dd tv@tv:~ dd bs=188 if=/dev/dvb/adapter0/caio0 of=test.mpeg ^Cdd: reading `/dev/dvb/adapter0/caio0': Resource temporarily unavailable 1338880+0 records in 1338880+0 records out 251709440 bytes (252 MB) copied, 34.3276 s, 7.3 MB/s dd: closing input file `/dev/dvb/adapter0/caio0': Bad file descriptor The first dd reports a more/less correct size for 30sec of encrypted tv ~ 18MB. But the 2nd dd shows a big generated file out of the device. Plus it mostly contains the following pattern : lots of FF separated by 47 1F FF 10. I hope you can guide me to solve this - it is getting painful. Can we review the code together ? The starting point should be the ts_write/read methods. -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ngene CI problems
Hi all! I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup: Software: Linux 2.6.34.8 (vanilla) drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ http://linuxtv.org/hg/%7Eendriss/v4l-dvb/ Hardware: Digital Devices CineS2 + CI Module Problems: - Packets get lost in SEC device: I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC. - SEC device generates NULL packets (ad infinitum): When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready. - SEC device blocks on CAM re-insertion: When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem. - SEC device does not respect O_NONBLOCK: In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK. Best regards, Martin Vidovic Hi, Running a bunch of test with gnutv and a DuoFLEX S2. I saw the same problem concerning the decryption with a CAM. I'm running kern 2.6.39 rc 4 with the latest patches from Oliver. Also applied the patch moving from SEC to CAIO. I would run gnutv like 'gnutv -out stdout channelname /dev/dvb/adapter0/caio0' and then 'cat /dev/dvb/adapter0/caio0 | mplayer -' Mplayer would complain the file is invalid. Simply running simply 'cat /dev/dvb/adapter0/caio0' will show me the same data pattern over and over. Anyone using ngene based card with a CAM running successfully ? -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ngene CI problems
Hi all! I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup: Software: Linux 2.6.34.8 (vanilla) drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ Hardware: Digital Devices CineS2 + CI Module Problems: - Packets get lost in SEC device: I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC. - SEC device generates NULL packets (ad infinitum): When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready. - SEC device blocks on CAM re-insertion: When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem. - SEC device does not respect O_NONBLOCK: In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK. Best regards, Martin Vidovic -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
