Re: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
Moikka! On 08.02.2014 15:28, David Jedelsky wrote: Manu, Antti, Thank you for explanation. Now I see that I patched wrong place. More appropriate would be to concentrate on az6027 I2C code. Maybe my device could be working with corrected I2C code. And yes, I have to confirm that the current I2C interface code is very strange. Especially that address checking, which really suggests that there is something wrong. I looked at the PCB and there isn't too much information written there ...just SkyStar USB 2 HD CI REV 2.0. Here are images (taken little bit from the side to be IC labels visible) http://djed.cz/skystar-usb-2-hd-ci-bottom.jpg http://djed.cz/skystar-usb-2-hd-ci-top.jpg and closeup of stb0899 http://djed.cz/skystar-usb-2-hd-ci-stb0899.jpg Regarding the firmware (btw. just for curiosity you can see from the images that the actual controller is CY7C68013A). At some point I have extracted the firmware sent by windows driver from the USB communication and it was the same as the Linux one. I can try to look for some updates. You likely already know, but lets say, CY7C68013A is general USB bridge having firmware which defines how it behaves. There is open DVB firmware for that chip somewhere on LinuxTV.org cvs. I hacked it once successfully for one device, relatively small changes were needed. STB0899 is demodulator. And that small chip near antenna connector is tuner. Altera is fpga, running custom logic. It implements common interface. LC245A near Altera is likely TS (transport stream, picture is here) switch. Parallel TS used. It routes TS via CI or directly to CY7C68013A. Cypress datasheets are rather open, you could easily check which are I2C pins. If you has hardware sniffer, Bus Pirate, oscilloscope, etc. you could easily sniff I2C bus and look if it uses repeated START condition for register reads. regards Antti Regards, David On Fri, Feb 7, 2014 at 10:46 PM, Manu Abraham abraham.m...@gmail.com mailto:abraham.m...@gmail.com wrote: On Sat, Feb 8, 2014 at 2:41 AM, Antti Palosaari cr...@iki.fi mailto:cr...@iki.fi wrote: On 07.02.2014 22:54, Manu Abraham wrote: On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com mailto:david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't
Re: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. -- 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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On 07.02.2014 22:54, Manu Abraham wrote: On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. It is almost 100% sure I2C adapter or client bug. az6027 driver i2c adapter seems to have some weird looking things, it behaves differently according I2C slave address used. If I didn't read code wrong, in that case it does to branch if (msg[i].addr == 0xd0). And looking that logic reveals it supports only 2 I2C transfers: for reg read: START + write + REPEATED START + read + STOP for reg write: START + write + STOP So that read operation (START + read + STOP) used by STB0899 is not implemented at all. regards Antti -- http://palosaari.fi/ -- 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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
On Sat, Feb 8, 2014 at 2:41 AM, Antti Palosaari cr...@iki.fi wrote: On 07.02.2014 22:54, Manu Abraham wrote: On Sat, Feb 8, 2014 at 1:19 AM, David Jedelsky david.jedel...@gmail.com wrote: That changes I2C functionality from STOP + START to repeated START. Current functionality looks also very weird, as there is 5 messages sent, all with STOP condition. I am not surprised if actually bug is still in adapter... Somehow it should be first resolved how those messages are send, with repeated START or STOP. And fix I2C client or adapter or both. regards Antti Manu, Antti, Thank you for your response. I agree that the code is somewhat peculiar and it could be worthy to review it using documentation before I leave it as bug in my hw. Unfortunately I don't own appropriate documentation. If you can supply it I can look at it. I can assure you that the STB0899 driver works well for S2 with most USB bridges and PCI bridges, which brings me to the fact that the issue does not exist with the STB0899 driver. Regarding the documentation, I don't have any wrt to the USB bridge, but only for the demodulator, tuner. But my hands are tied on that front, due to NDA's and agreements. Looking further in my hardware museum, I did find a Technisat Skystar USB2 HD CI REV 2.0 The information on a white sticker on the PCB states: Model AD-SB301, Project ID: 6027 DVB-S2, CI, USB Box (on-line update) H/W Ver: A1, PID/VID: 14F7 / 0002 manufactured and sent to me by Azurewave. It has a broken ferrite cored inductor on it, which appears to be on the power line to the demodulator/tuner. The PID/VID looks exactly the same as yours. If you have a firmware bug, maybe it helps to update the firmware online ? (I guess the windows driver uses some stock Cypress driver, from what I can imagine ?) I had similar problems as you state, when I worked with a prototype version of the Mantis PCI chipset where it had some issues regarding repeated starts. I can't really remember the exact issue back then, but I do remember the issue being tuner related as well, since the write to the tuner would reach the very first tuner register alone. The communications to the tuner are through a repeater on the demodulator. This issue was addressed with an ECO Metal fix for the PCI bridge, but that did eventually result in a newer chip though. The problem could likely be similar with your USB bridge. Maybe it is a driver bug too .. I haven't looked deeply at the az6027 driver. It is almost 100% sure I2C adapter or client bug. az6027 driver i2c adapter seems to have some weird looking things, it behaves differently according I2C slave address used. If I didn't read code wrong, in that case it does to branch if (msg[i].addr == 0xd0). And looking that logic reveals it supports only 2 I2C transfers: ACK. I looked at the code, just now. The I2C interface code looks garbage! for reg read: START + write + REPEATED START + read + STOP for reg write: START + write + STOP So that read operation (START + read + STOP) used by STB0899 is not implemented at all. To be a bit more specific; the STB0899 S2 part. The STB0899 has a different (but standard) I2C interface for the DVB-S demodulator and a different one with 16/32 bit registers for the DVB-S2 demodulator. The USB-I2C interface code for the bridge doesn't implement this interface. But I see some still more weirdness in there with comments; /* demod 16 bit addr */. There's a knot in my head, right now. AFAICS, the overall I2C communication with the STB0899 is very standard, generic I2C according to the official I2C specifications and documentations. All STB0899 specific handling is done within the demodulator read/write routines. If the I2C host interface with the USB device works in a standard way, then the device should work as-is with no changes to any frontend drivers. Regards, Manu -- 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
[PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
My TechniSat SkyStar 2 HD CI USB ID 14f7:0002 wasn't tuning DVB-S2 channels.
Investigation revealed that it doesn't read DVB-S2 registers out of stb0899.
Comparison with usb trafic of the Windows driver showed the correct
communication scheme. This patch implements it.
The question is, whether the changed communication doesn't break other devices.
But the read part of patched _stb0899_read_s2reg routine is now functinally
same as (not changed) stb0899_read_regs which reads ordinrary DVB-S registers.
Giving high chance that it should work correctly on other devices too.
Signed-off-by: David Jedelsky david.jedel...@gmail.com
---
drivers/media/dvb-frontends/stb0899_drv.c | 44 +++--
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/media/dvb-frontends/stb0899_drv.c
b/drivers/media/dvb-frontends/stb0899_drv.c
index 07cd5ea..3084cb2 100644
--- a/drivers/media/dvb-frontends/stb0899_drv.c
+++ b/drivers/media/dvb-frontends/stb0899_drv.c
@@ -305,19 +305,20 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
.len= 6
};
- struct i2c_msg msg_1 = {
- .addr = state-config-demod_address,
- .flags = 0,
- .buf= buf_1,
- .len= 2
+ struct i2c_msg msg[] = {
+ {
+ .addr = state-config-demod_address,
+ .flags = 0,
+ .buf= buf_1,
+ .len= 2
+ }, {
+ .addr = state-config-demod_address,
+ .flags = I2C_M_RD,
+ .buf= buf,
+ .len= 4
+ }
};
- struct i2c_msg msg_r = {
- .addr = state-config-demod_address,
- .flags = I2C_M_RD,
- .buf= buf,
- .len= 4
- };
tmpaddr = stb0899_reg_offset 0xff00;
if (!(stb0899_reg_offset 0x8))
@@ -326,6 +327,7 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
buf_1[0] = GETBYTE(tmpaddr, BYTE1);
buf_1[1] = GETBYTE(tmpaddr, BYTE0);
+ /* Write address*/
status = i2c_transfer(state-i2c, msg_0, 1);
if (status 1) {
if (status != -ERESTARTSYS)
@@ -336,28 +338,16 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
}
/* Dummy*/
- status = i2c_transfer(state-i2c, msg_1, 1);
- if (status 1)
- goto err;
-
- status = i2c_transfer(state-i2c, msg_r, 1);
- if (status 1)
+ status = i2c_transfer(state-i2c, msg, 2);
+ if (status 2)
goto err;
buf_1[0] = GETBYTE(stb0899_reg_offset, BYTE1);
buf_1[1] = GETBYTE(stb0899_reg_offset, BYTE0);
/* Actual */
- status = i2c_transfer(state-i2c, msg_1, 1);
- if (status 1) {
- if (status != -ERESTARTSYS)
- printk(KERN_ERR %s ERR(2), Device=[0x%04x], Base
address=[0x%08x], Offset=[0x%04x], Status=%d\n,
- __func__, stb0899_i2cdev, stb0899_base_addr,
stb0899_reg_offset, status);
- goto err;
- }
-
- status = i2c_transfer(state-i2c, msg_r, 1);
- if (status 1) {
+ status = i2c_transfer(state-i2c, msg, 2);
+ if (status 2) {
if (status != -ERESTARTSYS)
printk(KERN_ERR %s ERR(3), Device=[0x%04x], Base
address=[0x%08x], Offset=[0x%04x], Status=%d\n,
__func__, stb0899_i2cdev, stb0899_base_addr,
stb0899_reg_offset, status);
--
1.7.10.4
--
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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
Moi David
On 06.02.2014 11:45, David Jedelsky wrote:
My TechniSat SkyStar 2 HD CI USB ID 14f7:0002 wasn't tuning DVB-S2 channels.
Investigation revealed that it doesn't read DVB-S2 registers out of stb0899.
Comparison with usb trafic of the Windows driver showed the correct
communication scheme. This patch implements it.
The question is, whether the changed communication doesn't break other devices.
But the read part of patched _stb0899_read_s2reg routine is now functinally
same as (not changed) stb0899_read_regs which reads ordinrary DVB-S registers.
Giving high chance that it should work correctly on other devices too.
That changes I2C functionality from STOP + START to repeated START.
Current functionality looks also very weird, as there is 5 messages
sent, all with STOP condition. I am not surprised if actually bug is
still in adapter... Somehow it should be first resolved how those
messages are send, with repeated START or STOP. And fix I2C client or
adapter or both.
regards
Antti
Signed-off-by: David Jedelsky david.jedel...@gmail.com
---
drivers/media/dvb-frontends/stb0899_drv.c | 44 +++--
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/media/dvb-frontends/stb0899_drv.c
b/drivers/media/dvb-frontends/stb0899_drv.c
index 07cd5ea..3084cb2 100644
--- a/drivers/media/dvb-frontends/stb0899_drv.c
+++ b/drivers/media/dvb-frontends/stb0899_drv.c
@@ -305,19 +305,20 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
.len= 6
};
- struct i2c_msg msg_1 = {
- .addr = state-config-demod_address,
- .flags = 0,
- .buf= buf_1,
- .len= 2
+ struct i2c_msg msg[] = {
+ {
+ .addr = state-config-demod_address,
+ .flags = 0,
+ .buf= buf_1,
+ .len= 2
+ }, {
+ .addr = state-config-demod_address,
+ .flags = I2C_M_RD,
+ .buf= buf,
+ .len= 4
+ }
};
- struct i2c_msg msg_r = {
- .addr = state-config-demod_address,
- .flags = I2C_M_RD,
- .buf= buf,
- .len= 4
- };
tmpaddr = stb0899_reg_offset 0xff00;
if (!(stb0899_reg_offset 0x8))
@@ -326,6 +327,7 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
buf_1[0] = GETBYTE(tmpaddr, BYTE1);
buf_1[1] = GETBYTE(tmpaddr, BYTE0);
+ /* Write address*/
status = i2c_transfer(state-i2c, msg_0, 1);
if (status 1) {
if (status != -ERESTARTSYS)
@@ -336,28 +338,16 @@ u32 _stb0899_read_s2reg(struct stb0899_state *state,
}
/* Dummy*/
- status = i2c_transfer(state-i2c, msg_1, 1);
- if (status 1)
- goto err;
-
- status = i2c_transfer(state-i2c, msg_r, 1);
- if (status 1)
+ status = i2c_transfer(state-i2c, msg, 2);
+ if (status 2)
goto err;
buf_1[0] = GETBYTE(stb0899_reg_offset, BYTE1);
buf_1[1] = GETBYTE(stb0899_reg_offset, BYTE0);
/* Actual */
- status = i2c_transfer(state-i2c, msg_1, 1);
- if (status 1) {
- if (status != -ERESTARTSYS)
- printk(KERN_ERR %s ERR(2), Device=[0x%04x], Base
address=[0x%08x], Offset=[0x%04x], Status=%d\n,
- __func__, stb0899_i2cdev, stb0899_base_addr,
stb0899_reg_offset, status);
- goto err;
- }
-
- status = i2c_transfer(state-i2c, msg_r, 1);
- if (status 1) {
+ status = i2c_transfer(state-i2c, msg, 2);
+ if (status 2) {
if (status != -ERESTARTSYS)
printk(KERN_ERR %s ERR(3), Device=[0x%04x], Base
address=[0x%08x], Offset=[0x%04x], Status=%d\n,
__func__, stb0899_i2cdev, stb0899_base_addr,
stb0899_reg_offset, status);
--
http://palosaari.fi/
--
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: [PATCH] [media] stb0899: Fix DVB-S2 support for TechniSat SkyStar 2 HD CI USB ID 14f7:0002
Hi David, On Thu, Feb 6, 2014 at 3:15 PM, David Jedelsky david.jedel...@gmail.com wrote: My TechniSat SkyStar 2 HD CI USB ID 14f7:0002 wasn't tuning DVB-S2 channels. Investigation revealed that it doesn't read DVB-S2 registers out of stb0899. Comparison with usb trafic of the Windows driver showed the correct communication scheme. This patch implements it. The question is, whether the changed communication doesn't break other devices. But the read part of patched _stb0899_read_s2reg routine is now functinally same as (not changed) stb0899_read_regs which reads ordinrary DVB-S registers. Giving high chance that it should work correctly on other devices too. The patch does not look correct. STB0899 has a well documented I2C access method, which involves dummy reads, prior to any other. Also, the S2 regs access are different from the standard register access. That's the first part of the register access. The second part, According to 7914335A, the output buffer is not updated until a new address is requested. The controller returns the same value given in the first read operation. Thus the current code. So, most likely, all your modified read_s2reg would be reading incorrect data out of the registers that you requested; ie could be likely reading a standard register, or could possibly be returning data for some other read. With the current code, Without any changes S2 access does work correctly with most bridges. It's extremely strange such a change can cause things to work for you. From what I can see, your USB I2C interface has an incorrect or a bad implementation (I have seen such weirdness with some I2C implementations), which could be a likely explanation for your symptoms. Generally, a bug with the USB host device firmware, or a bug with USB-I2C driver is the most probable case. Best Regards, Manu -- 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
2x TT CT-3650 CI USB = corrupt video
Individually each of them work. When both of them are connected I get corrupted video as soon as I tune to another channel. There is no specific pattern in the logs, but now and then trouble about too large packets when communicating with the CAM appears in dmesg, which could make sense given the pervasive use of encryption by my cable provider. I have kept a log of most of the things I've already tried here: http://ubuntuforums.org/showthread.php?t=2054643 Is this a common problem when you use two of the same tuners? Who can help me fix this problem? Henk Poley -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue (Tuesday) 08.Jun (June) 2010, 12:14, Bjørn Mork wrote: Markus Rechberger mrechber...@gmail.com writes: Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Ouch. That makes me wonder about the state of the Windows drivers for those devices... Better stay away from them, I guess. Just to throw this out there, the 'doze support for one such Micronas-based device I have -- the Linux kernel support for which either does not exist or cannot be publicly distributed -- is less than optimal in my experience, which may have nothing to do with reality. While I was able to make a flawless test recording for a few minutes of one medium-bitrate lower-resolution high-definition programme to mislead me into thinking that I'd have success with a full-length programme, for some reason it turned out that my use of the device under 'doze for an extended time on a borrowed 'doze box suffered fairly frequent problems manifested each as a short dropout of the recording. This could also be pilot error, as I remain willfully ignorant of 'doze and its details, but if a machine with CPU horsepower over eight times that (neglecting other acceleration) of my workhorse that routinely makes four simultaneous flawless recordings including some at higher resolution/bitrate, is unable to keep up with the bitstream, then something has got to be seriously wrong, in my opinion. A later recording of a higher bitrate (excellent quality standard- definition video source) stream again exhibited the same problem. Perhaps 'doze can't keep up writing to its own native filesystem as it approaches being full, or if I can't keep my hands away from configuring it to be user-hostile as I prefer. And of course there's the factor of intermediate hardware to be considered -- my device is connected via a USB interface which has caused major filesystem corruption over time with the particular Linux kernel I was using, despite of working flawlessly with a different video card. And 'doze... *shiver* Anyway, I'd be happy to learn that others have had success with the same device, although for me it's no longer a priority to have it working, to say nothing of working perfectly. My testing of the device has been relatively minimal, using it where other tuner cards lack support. barry bouwsma -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue, June 8, 2010 08:26, Tobias Maier wrote: The Micronas DRX series seems to 'evil' in that there is only a closed-source driver and the manufacturer doesn't cooperate with open source developers. Have you asked them or are you simply asuming this because there is no open source driver? It is important to notice that the vendor (Trident) doesn't seem to want helping with open source development. Contacts with the vendor were tried during 2007 and 2008 in order to get their help by opening docs, via Linux Foundation NDA program, without success. The vendor also seems to be refusing so far to help the development of a driver for their demod DRX-K line that they acquired from Micronas (as pointed at http://linux.terratec.de/tv_en.html). (http://www.linuxtv.org/wiki/index.php/Trident_TM6000) -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue, Jun 8, 2010 at 10:03 AM, Jan-Pascal van Best janpas...@vanbest.org wrote: On Tue, June 8, 2010 08:26, Tobias Maier wrote: The Micronas DRX series seems to 'evil' in that there is only a closed-source driver and the manufacturer doesn't cooperate with open source developers. Have you asked them or are you simply asuming this because there is no open source driver? It is important to notice that the vendor (Trident) doesn't seem to want helping with open source development. Contacts with the vendor were tried during 2007 and 2008 in order to get their help by opening docs, via Linux Foundation NDA program, without success. The vendor also seems to be refusing so far to help the development of a driver for their demod DRX-K line that they acquired from Micronas (as pointed at http://linux.terratec.de/tv_en.html). (http://www.linuxtv.org/wiki/index.php/Trident_TM6000) We have been working on getting those chipsets work with our devices. http://sundtek.com/shop/Digital-TV-Sticks/Sundtek-MediaTV-Digital-Home-DVB-CT.html Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Best Regards, Markus -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
Markus Rechberger mrechber...@gmail.com writes: Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Ouch. That makes me wonder about the state of the Windows drivers for those devices... Better stay away from them, I guess. Bjørn -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On Tue, Jun 8, 2010 at 12:14 PM, Bjørn Mork bj...@mork.no wrote: Markus Rechberger mrechber...@gmail.com writes: Trident is also still improving the quality of their driver and firmware, it very much makes sense that they handle their driver especially since those DRX drivers are very complex (basically too complex for being handled by the community, the drivers would just end up somewhere unmaintained). Ouch. That makes me wonder about the state of the Windows drivers for those devices... Better stay away from them, I guess. If you have issues with your Windows driver you should contact the manufacturer of your device. If they care about their product and/or some customer relation they will try to help you. Markus -- 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
Is anybody working on TechniSat CableStar Combo HD CI USB device?
This is the device: http://www.technisat.com/index9332.html?nav=PC_products,en,76-229 lsusb: Bus 001 Device 005: ID 14f7:0003 on the card is a Micronas DRX 3913 JKA2 which is a combined analog cable, DVB-C and DVB-T Demodulator. best hit I can get with google is http://www.tridentmicro.com/producttree/tv/dtv/drx/drx-39xyk/ any chance this device is supported soon? Anything i can do to get this going? -- 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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On 06/07/2010 09:01 AM, Tobias Maier wrote: on the card is a Micronas DRX 3913 JKA2 which is a combined analog cable, DVB-C and DVB-T Demodulator. any chance this device is supported soon? Anything i can do to get this going? Hi Tobias, I'm in the market for a USB DVB-C device, and I've been looking into this device. I've added it to the linuxtv.org wiki (http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI). It seems the Windows drivers for this device are very similar to those of the (supported) Terratec S7 DVB-S device. No quite sure that to make of that, though. The Micronas DRX series seems to 'evil' in that there is only a closed-source driver and the manufacturer doesn't cooperate with open source developers. Jan-Pascal signature.asc Description: OpenPGP digital signature
Re: CI USB
On 24 January 2010 09:56, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 10:54 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller typo, 40 A0 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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 According to this page http://www.bsc-bvba.be/linux/dvb/ the firmware load problem was solved about a month ago What is needed in the way of resources to solve this problem? Regards -- 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: CI USB
On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 10:54 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller typo, 40 A0 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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: CI USB
On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. Regards, Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... Regards, Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) also, i can confirm that firmware extractor here: http://www.bsc-bvba.be/linux/dvb/ is correct at least for A2 hardware (but A1 hardware is no longer in production anyway), because a long time ago i verified with spying the USB traffic what firmware is uploaded in Windows for A2 hardware and informed Luc Brosens and he fixed his firmware extractor tool. however, it seems that the main problem as it's mentioned by Luc Brosens is why firmware upload fails in Linux, because according to Steven Toth words: * http://www.linuxtv.org/pipermail/linux-dvb/2008-April/025284.html * I also looked at the USB traffic on the current Hauppauge driver, with a * cam inserted and decryption happening. The protocol appears pretty simple. after the firmware is uploaded is easy to figure out how to send commands to the device. Regards, Manu -- 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: CI USB
On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip Regards, Manu -- 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: CI USB
HoP a écrit : I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza Just a quick note here: you might want to post to the mythtv ML and the VDR one also (probably others but I dont know them off hand) and see how people feel about this. My guess is that quite a few potential users are on these ML, and the CI threads are recurrent there because of good dvb-s cards but without CI support. A usb-CI or equivalent HW + good drivers would allow people to pick the dvb-s(2) cards without worrying about CI support. HTH Bye Manu -- 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: CI USB
Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu -- 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: CI USB
On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu Regards, Mmanu -- 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: CI USB
I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza -- 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: CI USB
HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. Hiya, I've been reading this mailing list with regards to using a USB CI, but hadn't found anything to help until I found the posts from Luc and Steve sometime ago about getting the WinTV-CI to work under Linux. Coincidently, at the end of last year I had e-mailed Luc about the WinTV-CI, to see if I can help. I'm in the process of purchasing some hardware to start testing. He had managed to grab the firmware from the Windows driver but had so far been unable to get it to load correctly in his new driver. Regards, Ian Wilkinson -- 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: CI USB]
Manu Abraham wrote: On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Also some card (at least for DVB-S) are really good but targeted towards free channels, and in France for example, alot of good channels are not. If the price is right (tm) I am sure a lot of people would be interested. Bye Manu Regards, Mmanu Here in Belgium and the Netherlands all channels are encrypted and besides the economics, I have very little possibility to view those channels. (not since my nexus-S with dual CI is not keeping up with the latest developments anymore). I now own a HVR4000, but Hauppauge are only supporting the USB CI for all new cards and apparently dropped the flatcable direct connection to a CI interface. There is software available to use a USB cardreader, which I am using now. This software however permits illegal distribution of keys as well. Interesting though is that this software doesn't use the official CI, nor a CAM, but a generic USB smartcard reader. If a solution could be developed, which is manufacturer independent, does not use a CAM and does not permit illegal use that would be great... regards, Johan -- 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: CI USB
Manu Abraham a écrit : On Sun, Jan 10, 2010 at 5:09 PM, Emmanuel eall...@gmail.com wrote: Markus Rechberger a écrit : On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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 Well I dont know for others but it really looks interesting as you can have multiple cards with only one CI, meaning only one CAM and only one subscription card which is economically interesting. I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But then you would be better of buying multiple CAM's for a home use purpose. Well my Astoncrypt is able to descramble 2 channels simultanueously, but here the good thing would be that you could descramble after the recording, so that you would be able for example to capture 4 channels on the same transponder only to descramble one by one later on. Bye Manu -- 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: CI USB
On Sat, Jan 2, 2010 at 11:55 PM, HoP jpetr...@gmail.com wrote: Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- 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: CI USB
BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. The whole project went badly wrong when the hardware vendor promised documentation then failed to deliver. My mistake for trusting them in the first place. I had considered running a driver reverse engineering tutorial project via kernellabs.com. Perhaps a 4 part series of writings, tools and instructions that describe how to reverse engineer USB drivers and culminates in a working skeleton driver for the WinTV CI that could be used. I doubt I could make this happen without a project sponsor so if you know any companies that would be willing to sponsor a project like this then I'd certainly be interested in helping. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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
CI USB
Hi All, Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. Cheers, - jonas -- 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: CI USB
Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. /Honza -- 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
