342 replies to this topic

[Lost in Space]

30 secs of searching

 

https://forums.openp...ndpost&p=583753

 

https://github.com/o...sions/SocketMMI

Edited by gutemine, 12 April 2017 - 16:19.

[Frenske]

I have hidden all not related postings.
To ALL concerned. Behave like adults and stop pointing fingers to each other.

[Dream1975]

Not to dig up an old discussion, but it seems OpenATV/OpenVIX etc have removed the CI+ support from their standard image (probably also not to get into legal problems). CI+ support can be reinstated by installing the ciplushelper plugin (I shall not link to it but with Google they are easy to find, it is even maintained on github).

 

I have the old ciplushelper v1.1 which works perfectly with OpenPLi 6.1 on my HD2400 (tested with a Ziggo CI+ module). When downloading/installing the latest version (currently 4.4) I get below error message:

 

 

root@Enigma2WK:/media/hdd# opkg install enigma2-plugin-systemplugins-ciplushelper_4.4-r0_all.ipk
Installing enigma2-plugin-systemplugins-ciplushelper (4.4) on root.
python: can't open file '/usr/lib/enigma2/python/BoxBrandingTest.pyo': [Errno 2] No such file or directory
 Removing any system startup links for ciplushelper ...
 Removing any system startup links for cihelper.sh ...
Configuring enigma2-plugin-systemplugins-ciplushelper.
root@Enigma2WK:/media/hdd#

 

This is probably because the 1.1 version was specific for the HD2400 and they now have made a general ciplushelper that works on most recievers (but the plugin now calls upon the mentioned boxbrandingtest.pyo).

 

Isn't it possible to adapt OpenPLi so it will be compatible with this plugin (by obtaining/adding the boxbrandingtest if possible)? I dont know if adding the boxbrandingtest.pyo in the image will make it work, but as v1.1 does work in OpenPLi 6.1 my hopes are up.

 

This way there is no illegal CI+ certificate in OpenPLi (nor is the ciplushelper available in the feed) but people might get CI+ to work if they would find, download and install the plugin themselves (because it is ridiculous that the CI+ consortium decides on what devices you can use your paid subscription).

 

It might be worth a try...

Edited by Dream1975, 3 March 2018 - 06:54.

[littlesat]

i would say decompie the stuff and work a round the box branding module which is most likely not required at all...
And note all ci+ helper stuff can only work when a lisence is included..

Edited by littlesat, 3 March 2018 - 08:02.

[Dream1975]

Even if I knew how to decompile and adapt the plugin, I don't think that would be the best solution. A special version of the plugin would then have to be made (and hosted somewhere) just for OpenPLi (and therefore the version users will download from the internet still won't work).

 

Curious as I am I downloaded BoxBrandingTest.pyo here (first hit on Google) and put it as a test at /usr/lib/enigma2/python/ after which I tried to reinstall ciplushelper 4.4. Unfortunately I get another error message that the branding module can't be found. I found the module at https://github.com/o...ter/BoxBranding but could someone tell me where to put the files (or the command line entry to install the module as it is available on github)? I will then test again.

 

If I get it to work this way the team might consider adding the boxbranding (from github, it has a GNU license) so OpenPLi will also work with CI+ modules (if the user installs the plugin manually). Or place a ""dummy" boxbranding.pyo that doesn't call upon the module but takes care of the error upon installing the plugin. But that's another thing (and that's for the team to decide if, and if so how, they would like the image to be compatible with ciplushelper). For now I am just curious if the plugin works on OpenPLi if the boxbranding errors won't stand in the way of install.

[littlesat]

The Oe-a community made a seperate binary that is needed for the branding stuff... so indeed that does not help either...

Edited by littlesat, 3 March 2018 - 10:20.

[betacentauri]

You cannot (in many cases) just copy box branding stuff on a OpenPLi box. The .so library is compiled for a specific box. So in your case it only works with a hd2400 version of the boxbranding library.

[arn354]

the ipk uses boxbranding as it includes several ways to install cihelper files for different boxes and architectures (mips32el,arm). You could also split the ipk box and/or arch specific - then it needs no boxbranding. basically the ipk decides based on boxbranding which files to install.

[Dream1975]

the ipk uses boxbranding as it includes several ways to install cihelper files for different boxes and architectures (mips32el,arm). You could also split the ipk box and/or arch specific - then it needs no boxbranding. basically the ipk decides based on boxbranding which files to install.

 

That would explain why ciplushelper 1.1 does install and work. It is from the time before there were ARM boxes and therefore didn't need boxbranding as everything was mipsel. But this does strengthen my suspicion that the general available ciplushelper plugin will work on OpenPLi and therefore CI+ can be used through this way, if this issue would be tackled. It would seem to me that CI+ support (through a user downloading and installing the plugin from the internet) would make a lot of OpenPLi users happy (German users, users with a Joyne subscription etc).

Edited by Dream1975, 3 March 2018 - 10:38.

[Erik Slagter]

Even if we would spend a considerate amount of time getting this to work, there is no guarantee it will keep working for.... a month, a week? And it also will only work on a very selected group of receivers. I'd rather spend my limited time on keeping basic core functionality working. But who knows, someone thinks otherwise and is willing to spend that time.

[Dream1975]

The ciplushelper v1.1 has worked from 2014 onwards on my HD2400 and Ziggo CI+ module (on OpenPLi 4/6/6.1), so it seems very stable in combination with OpenPLi.

 

I understand you guys are very busy, so maybe somebody else might have a billiant idea how to tackle the boxbranding issue (I wish I could, but unfortunately I'm just a simple user and not a programmer).

 

But if somebody would now a solution there would be a lot of gratefull users I presume (for example people with a Ziggo Nagra CI+, Joyne, HD+ viewers etc). Unfortunately CI+ is getting used more and more and it would be a pity if people weren't able to use OpenPLi anymore because their provider switched to CI+, while it seems the ciplushelper is able to run on OpenPLi (as it works perfectly on my HD2400) and there are no conflicts (other than the boxbranding in the newer versions of the helper).

Edited by Dream1975, 3 March 2018 - 13:53.

[littlesat]

We can even not start implementing something as we do not want the "CI+ police" does arrest us....

Edited by littlesat, 3 March 2018 - 14:24.

[Dream1975]

I understand, but OpenPLi would still have nothing to do with providing CI+ functionality or certificates. The only thing OpenPLi has to do (as it would seem now) is that plugins can determine if the box is Mipsel or ARM (which other images do through the oe-alliances boxbranding module if I understand it correctly). This is completely seperate from the CI+ story as other (future) plugins might also need to determine what architecture the box has. If OpenPLi would also use the OE-alliances boxbranding this can be done and is the same as other images do (and keep the standard intact). Off course it would make the images a little bigger, but for current boxes this shouldn't be a problem (other images can also include the module and they have enough flash space).

 

A nice side effect of embrasing boxbranding is that users can download and install a ciplushelper plugin they find on the internet also, but that is just because the plugins dependencies (boxbranding module) are in the image. This module being in the image has nothing to do with providing CI+.

 

And if a user decides to download and install the plugin on their own it is their own responsibility and the PLi team has nothing to do with this. It's the same for example with Kodi. It is completely legal as it is offered on heir site, but if users install illegal plugins into it that is not the responsibility of Kodi.

Edited by Dream1975, 3 March 2018 - 14:56.

[Tech]

It is a misunderstanding that Joyne uses ci+, I tried several boxes without any ciplus helper at all and on every box the picture appaired.

[MastaG]

@Tech so joyne uses regular CI ?

[Tech]

Yes, or a CI+ without the activated '+ part'

It is a CI with an embedded (virtual) card so just a module without a cardslot.

[Erik Slagter]

@Dream1975 the only way we would be able to sustain CI+ support is:

 

- specifications of the interface need to be public (or at least known)

- someone witht the time and skills to implement a decent, open, "CI+ helper"

- certificates available in the "grey circuit"

 

I don't think it's something that should be "core business" from an image team, also it doesn't have to be anyway.

 

We've been saying this for years, but only some manufacturers come up with some lame implementations.

Edited by Erik Slagter, 4 March 2018 - 09:15.

[littlesat]

another ‘solution’ ate helpers via the Grey scene... just like ‘other images’ have for standard softcams... then the community can stop ‘bashing’ us..

Edited by littlesat, 4 March 2018 - 09:23.

[Erik Slagter]

The problem is that they don't have clean interface like softcams have, and mostly require adaptations to

- drivers

- enigma

- other OE parts

And all of them needing other adaptations. So that's never going to work (as we already see).

[Dream1975]

@Dream1975 the only way we would be able to sustain CI+ support is:

 

- specifications of the interface need to be public (or at least known)

- someone witht the time and skills to implement a decent, open, "CI+ helper"

- certificates available in the "grey circuit"

 

I don't think it's something that should be "core business" from an image team, also it doesn't have to be anyway.

 

We've been saying this for years, but only some manufacturers come up with some lame implementations.

 

I understand that you can't implement official CI+ support in OpenPLi as this would require the above points. That said there is already a solution available for a user to implement CI+ support by installing a plugin after which the CI handling of enigma2 can be enriched to also use CI+. This way no image maker has to provide CI+ support by themselves (and getting problems with the CI+ police) but boxes using an image with enigma's standard CI handling can be made to use CI+.

 

The nice thing about this plugin is that it also works on OpenPLi, without any adaptation of the image (as I have successfully tested with plugin version 1.1 on my HD2400 for years). Unfortunately V1.1 only supports a few boxes (mipsel).

 

Over time the plugin has gotten some improvements as to where it now supports (almost) all receivers the OE-alliance makes images for. Unfortunately newer versions won't install on OpenPLi beacuse it calls upon the OE-alliances boxbranding module (to determine and install the files from the plugin needed for the box it is installed on) that is not available in OpenPLi.

 

In short:

- A plugin that adds CI+ support to the existing CI handling in enigma2 is available

- Early versions (without boxbranding dependancy) install and work on OpenPLi out of the box

- The plugin is currently written to work on (almost) all enigma2 boxes the OE-alliance supports, the setup now checks the box brand/type using boxbranding to install the needed files for that specific box. Unfortunately as boxbranding isn't included in OpenPLi these newer versions won't install on OpenPLi

 

Considering the fact that the versions before the boxbranding check do install and work on standard OpenPLi without any adaptations, I feel confident the newer versions would also work if the install could be done.

I therefore have a strong feeling that if the boxbranding issue upon install could be tackeled, CI+ could be used on OpenPLi without the team having to do any (major) adaptations to the image.

 

In my humble opinion there are 2 possibilities to solve the issue:

1. The best solution would be to change the plugin so it determines the box (architecture) from the OS (instead of using the boxbranding module) to install the needed files. With this option the plugin creators have to be contacted (which I would be willing to do if I knew where to reach them) and should also be willing to make the adaption

2. OpenPLi adapts the image so when a plugin is installed and want's to make a call to the boxbranding module it can be fullfilled. For example by making boxbranding available (this could possibly also be done optionally as a dependency or something, so the module would only be installed when it is called upon and keep the standard image clean)

 

I'm not a programmer or anything so maybe my options are completely wrong or not possible, but if that isn't the case I see an opportunity to make OpenPLi boxes use CI+ without any/much changes in the image. Especially as enigma2's CI part needn't be adapted at all as the external plugin will take care of making enigma's standard CI handling also understand CI+.