Posts by m-snel

For more info about CI+ see also https://en.wikipedia.org/wiki/Common_Interface#History

Thank you for all the clarifications. If CI+ can't be used on enigma2 boxes the manufacturers will loose a lot of customers (as more and more providers only provide CI+ modules). I would suspect the manufacturers wouldn't like this and would probably embrace a possibility for it in the grey circuit.

We'll just have to see what the future brings then, fortunately my smartcards can still be used in OScam so I don't need it (for now).

Thank you for taking the time to enlighten me on the matter.

However you stated the drivers with a loophole have been replaced by OpenPLi (and images with the loophole don't need the plugin). I currently use OpenPLi 6.1 (build 26-2-2018) which contains a DVB driver dated 27-4-2017 on a Mut@nt HD2400. A CI+ module won't work on it when having a fresh OpenPLi install (it then gives a message that the module is not supported). But... when I install the ciplushelper v1.1 (and do nothing else) suddenly the CI+ module does work and decrypt the channels.

As for the ARM support, it is my understanding that the current ciplushelper 4.4 also supports ARM devices. If I download the ipk and extract it using 7-zip I see ARM containing boxes in it.

It would also seem that because of the CI+ consortium's warnings images that had CI+ support build in the code (like ATV) have removed it. These images now also need the plugin to add the necessary CI+ support code and certificates.

It is in the interest of both the manufacturers as the image builders for their boxes be able to use CI+. Although they can't officially provide it (due to legal reasons) I don't think they will try to block any workarounds. I wouldn't be surprised if in the background they are even cooperating in helping the plugin developers with advice how to support their boxes. This way they aren't providing anything illegal while (after some user action) their boxes can be made to use CI+.

I could be mistaking off course, but if I understand it correctly the DVB drivers are provided by the manufacturer and therefore the same ones are used in all images, and the needed certificate isn't included in the images (for legal reasons) and therefore provided by, and placed in the box, by the plugin (otherwise why would version 1.1 work on OpenPLi without any adaptation)?

I have a question about this plugin. I use OpenPLi and have an old ciplushelper v1.1 (which was a version before there were ARM boxes) that works great on OpenPLi on my HD2400. Newer versions won't install as they depend on the Boxbranding module which OpenPli doesn't use in their images (they have a policy of keeping the code as clean as possible and not put in too much extra stuff that isn't really required). As I understand from this post (posting 228) the boxbranding is called upon to decide if the processor is mipsel or ARM so it can install the appropriate files.

Now my question is why call upon the boxbranding module as the type of processor can also be obtained from the OS itself? It then needn't use boxbranding and would also install (and probably work because v1.1 does also work) on OpenPLi. It could be that I'm thinking too simple and boxbranding is also needed for other things, if so please let me know (I'm not a programmer but just a simple user). But I can also understand OpenPLi being not to keen to add boxbranding when they themselves have no further need for it in their image (and would only add code).

In short: Wouldn't it be possible to retrieve the boxtype/CPU architecture from the OS so this plugin doesn't need calling upon boxbranding? This way it would work on both oe based images as well as OpenPLi.