oscam working fine but newcamd protocol error: Invalid ecm type for card

think this thread is the same

No EMM received on Nagra Card

0100 to me not nagra

but it was asked

Hi.

Did you not test the Cccam protocol instead of Newcamd protocol (server+client) ? Just to test if it helps.

Hi.

Yes it's true. The problem can be caused by the processing of softcam-protocols, which is unfortunately non-standard in the case of Oscam - it is not original, so it does not affect the original softcams, according to the authors. In Oscam open code, someone is constantly fixing bugs. Often people who have no idea about coding systems. Also, each DVB provider can use slightly different methods in their own firmware, on their own decoder card. Then nothing works as it should.

If that doesn't help (using the cccam softcam-protocol), try using the communication softcam protocol, which is less well known but reliable - cs378x or cs357x (https://wiki.streamboard.tv/wi…fig/oscam.server#protocol).

I have a similar problem in CCCAM protocol communication. I have to use CCcam as a softcam-client, not OSCam as a softcam-client. I am using the CCcam 2.3.0 softcam-client for the mipsel chipset, which only works in an OpenATV image, without any problems. Other versions of CCcam softcam freeze, crash, do not work properly, etc. . This is IRDETO encoding card.

Oscam is probably only suitable as a server, not as a client.

The longer I use Oscam, the more I hate it. I've been using Oscam for about 4 years ... testing ... changing versions ... setting up a large number of different configurations on different types of DVB systems. But I still like Oscam softcam less and less.

So if your set-top box contains a mips(32)el chipset, then try to use Cccam-2.3.0 softcam as a client. Maybe it will help.

I really don't know why your Oscam will destroy the ECM format (readability).

Maybe you just misconfigured some items in the Oscam configuration related to ECM. Some settings may require, for example, an "ecmwhitelist" configuration item (but I don't know which one).

I don't know your DVB encoding, so I can't advise you anymore.

FatRabbit

It would be appropriate to create new binaries there. Backward compatibility with old versions of the system libraries (for example libcrypto, libssl, libusb, ...) usually doesn't work. However, in some specific cases, as I have already written, depending on the chipset in the set-top box (i.e. hardware dependent) and also depending on the Enigma distribution itself, even if the binary works, small problems may arise.

For example, specifically under mipsel processors, on the Linux kernel version 3.13 - the CCcam 2.3.2 softcam can freeze through new system libraries, while the CCcam 2.3.0 softcam works fine also in the new system libraries.

Linux systems are really great, but they require a lot of expert users and developers, unfortunately. Linux is not like Windows ... where you see 5 icons that you can click on and then the default task is performed (figuratively speaking). Linux is a universal solution ... but universal solutions also require people's hyper-intelligence :). And that's the stumbling block :).

So if you bought a new set-top box, it is quite possible that it is a coincidence that you hit the right version of the chipset, the appropriate distribution of Enigma, good softcam, DVB system coding of your provider, where everything is compatible and functional together.

///// EDIT :

Unfortunately, Oscam is similar in its versatility. Although it works always and everywhere, there are minor discrepancies, in various chipsets, libraries, DVB systems, etc..

Let me come up with a small example for understanding:

For the CONAX DVB-encoding system, OSCam will use a decoding algorithm via the libcrypto system library. However, the libcrypto system library in version 1.0.2 does some algorithms a little differently than in version 1.0.0. Oscam therefore needs a patch to be able to process the output, in an algorithm from the libcrypto 1.0.2 library, as it did in version 1.0.0.

(This is just a fictional example. Don't take it seriously. It's just for better understanding !)

Unfortunately, no developer will do this patch in the near future because no softcam developer uses CONAX decoding. We could still associate the problem only with the case where OSCam is used only as a client, not as a server. This complex problem will not be solved until many years later, when finally some softcam developer encounters this problem at home and fixes it. Unfortunately, this is the fate of the universal OSCam.