Jump to content


Photo

One proc file for detecting the MACHINE in all enigma2 images.


  • Please log in to reply
772 replies to this topic

Re: One proc file for detecting the MACHINE in all enigma2 images. #181 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 1 August 2020 - 23:04

Lots of things are already obtained from systeminfo. OE-A images feeds this with some data from box branding, machine features as well as manual entries. PLI do similar but with hardware info.

Surely it makes sense to continue with that process? If that is agreed you can then go on to cross reference/replace names so that Enigma2 code reads variables from one place (API).

However, it won't resolve issues that are at build level.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

Re: One proc file for detecting the MACHINE in all enigma2 images. #182 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 1 August 2020 - 23:24

I don't care what it is, or how it is called. The point is that all images use the same interface. For EVERYTHING.

 

I know for example that lots of code in the OE-A world call boxbranding functions directly. So all that will have to go before a system like this is going to work. It really needs to be an abstraction layer.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #183 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 1 August 2020 - 23:25

SystemInfo is already somehow doing this..... as you have the same with dicts in python.... then instead of Boxinfo you can already do SystemInfo and extend that...

 

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #184 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 August 2020 - 06:11

Hi Guys,

 

I called the proposal "BoxInfo" because some people perceive an issue with "SystemInfo".  There was some quite specific objection to the "SystemInfo" name so I thought it appropriate to base the proposal on a different name to get all people to look as the proposal.  I don't care if the actual program is called "SystemInfo", or anything else for that matter .  If we choose to stay with "SystemInfo" the we just need to transition from direct access to the dictionary items to an API interface.  If people are happy to accept the name "SystemInfo" I am more than happy to rename the proposal.

 

@WanWizard, what API do you think will be applicable for a shell?  I would have thought that we would use normal shell commands to directly access the source data in "/etc/enigma2/systeminfo".  For C++ I would assume that the data could be obtained via the Python API layer.  I am thinking that the Python API should be dominant as I suspect that most interaction with the API will be at the Python layer.  If that is deemed unacceptable then it would be easy to write an equivalent C++ API that also uses the same base data in "/etc/enigma2/systeminfo".

 

Regards,

Ian.



Re: One proc file for detecting the MACHINE in all enigma2 images. #185 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 2 August 2020 - 07:24

If you are going to use a different file to system info, best to use a different name.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

Re: One proc file for detecting the MACHINE in all enigma2 images. #186 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 2 August 2020 - 08:17


SystemInfo is already somehow doing this..... as you have the same with dicts in python.... then instead of Boxinfo you can already do SystemInfo and extend that...

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.
That was why I came up using the config system.... that is already available in cpp (except for threaded cpp a work a round is needed)..: why don’t use stuff that is already doing it?! The. You also have one ‘master’ without duplicates and experts may also manipulate it via /etc/settings... but again this is implementation...

Edited by littlesat, 2 August 2020 - 08:20.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #187 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 August 2020 - 11:41

Hi Littlesat,

 

Regarding the config option, if I was looking at the correct code in C++ I noticed that there were deliberate delays to wait for code to synchronise.  If that is really the type of implementation that you prefer then I will need to voice a vote against any such code.  Any code that relies on random timed sleeps or delays to make the code would should never be used as a preferred solution.  Too many code failures occur because of timing errors.  This should not be our preferred design.

 

Regards,

Ian.



Re: One proc file for detecting the MACHINE in all enigma2 images. #188 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 2 August 2020 - 12:27

Where did you find that wait stuff?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #189 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 2 August 2020 - 12:40

Can I pull this discussion back up to helicopter level please?

 

We need a solution for:

  • Python
    This should be a pure Python interface, again with no dependencies.
     
  • C
    This should be a pure C interface, with no dependencies.
     
  • (Bash) Shell
    This requirement dictates it should either be a file you can source in your bash script, or an executable you can call which returns the requested value. The executable has my preference, as it provides more flexibility to add logic (which we need in our 1 MACHINE = multiple models system). Given the environment we're in, it could either be a C binary (using the C interface internally) or a Python script, using the Python interface internally.

For all it is true that what happens behind the interface is a black box, implementation, and therefore not relevant for this discussion.

 

As to implementation, If we as OpenPLi decide that the C method should call a Python method to retrieve a value, it is entirely up to us. Not relevant for other teams, and not relevant for developers that need access to the box data. However, given the fact that Littesat's suggestion of using the Config system means you have to run under Enigma, and bash scripts don't, that rules that sort of implementation out.

 

The most logical is, like others have already discovered, is to create a OE level solution, that slots into Enigma at compile time.

 

But again, it is pointless talking about implementation as long as we don't have all other teams on board.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #190 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 2 August 2020 - 14:52

 

 

SystemInfo is already somehow doing this..... as you have the same with dicts in python.... then instead of Boxinfo you can already do SystemInfo and extend that...

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.
That was why I came up using the config system.... that is already available in cpp (except for threaded cpp a work a round is needed)..: why don’t use stuff that is already doing it?! The. You also have one ‘master’ without duplicates and experts may also manipulate it via /etc/settings... but again this is implementation...

 

Using "config system" is just another workaround/hack. And relies on enigma being active. BoxBranding never needed enigma to be active, so definitely a backwards step.


Edited by Huevos, 2 August 2020 - 14:53.


Re: One proc file for detecting the MACHINE in all enigma2 images. #191 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 2 August 2020 - 15:13

A simple (read only) file or proc already solve that.... without boxbranding code running in a thread...

Edited by littlesat, 2 August 2020 - 15:19.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #192 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 2 August 2020 - 15:19

@WanWizard, OpenATV already have a "CPP" implementation. It is called "modelinformation". And is also available in Python.

 

https://github.com/o...information.cpp



Re: One proc file for detecting the MACHINE in all enigma2 images. #193 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 2 August 2020 - 15:26

Yes openatv had it.... we already know that... but is is not a holy gray... it is an implementation or should I also call it hack?!. we’re trying to design something better...
Actually that thing is reading a static file and creates a dictionary of it.... so another clone of something that we already have on a file and double in python... then better keep it somehow once and swig it.

Edited by littlesat, 2 August 2020 - 15:29.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #194 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 2 August 2020 - 17:20

@WanWizard, OpenATV already have a "CPP" implementation. It is called "modelinformation". And is also available in Python.

 

https://github.com/o...information.cpp

 

I could live with that API without issues. What is the E2 equivalent, as that doesn't seem to be called ModelInformation? Or do you mean call eModelInformation from Python?

 

Just wondering though,why if ATV has this, is their E2 code littered with boxbranding calls?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #195 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 2 August 2020 - 20:06

@Wanwizard, you keep refering to one box for multiple receivers. And your posts suggests that you are implying that OE-A do not have it. Are you 100% sure of this? For Example, the Ceryon, Ini, Dags have "family" of receivers where most of the code is the same but allows you to  have specific/unique attributes for the "siblings" in the family. The build process duration for first child is as normal, but for second, third child, minor adjustments are made.



Re: One proc file for detecting the MACHINE in all enigma2 images. #196 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 2 August 2020 - 20:13


 

Just wondering though,why if ATV has this, is their E2 code littered with boxbranding calls?

 

 

Because boxbranding allows you to check for features a machine/box has. An example in Vix which came off some changes in ATV. But as you say, that can be moved into the API so that E2 code just refers to the API.

 

https://github.com/O...Picon.py#L7:L13

 

 

 

 

 

 



Re: One proc file for detecting the MACHINE in all enigma2 images. #197 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 2 August 2020 - 20:35

@Wanwizard, you keep refering to one box for multiple receivers. And your posts suggests that you are implying that OE-A do not have it. Are you 100% sure of this? For Example, the Ceryon, Ini, Dags have "family" of receivers where most of the code is the same but allows you to  have specific/unique attributes for the "siblings" in the family. The build process duration for first child is as normal, but for second, third child, minor adjustments are made.

 

No, I wrote "one MACHINE for multiple receivers". As in the OE definition of MACHINE. Using your example, we build 1 image for all incarnations of the "dags family", OE-A builds 1 image for every receiver in that family.

 

Not really relevant for the discussion, the only point I want to make is that the implementation can be different from one image team to the next, dependent on their requirements. That doesn't change the API.

 

Because boxbranding allows you to check for features a machine/box has. An example in Vix which came off some changes in ATV. But as you say, that can be moved into the API so that E2 code just refers to the API.

 

That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.
 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #198 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 2 August 2020 - 21:15

It is very relevant because your objection to branding module as the API is mainly based on that misconception.

 


That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.

 

They are two different things, model information won't show you what a model can do.

 

To me, we already have an API for Enigma2 code, systeminfo.py. We need to expand it and import other definitions/functions. Yes, some of the definitions on OE-A images are in box branding, but it is a minor change to add them to system info. But you then get the "why not get data directly from source?" debate from those who do not accept your API need/definition.

 

For other higher level factors, boxbranding does that for OE-A images. Once the notion that "one image for multiple receivers"  is reconsidered as "one biscuit packaged in different wrappers", lots of things will fall in place.

 

BTW, OpenEight and TeamBlue are part of OE-A and they use mainly PLI E2 as far as I know.



Re: One proc file for detecting the MACHINE in all enigma2 images. #199 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 2 August 2020 - 22:30

Yes openatv had it.... we already know that... but is is not a holy gray... it is an implementation or should I also call it hack?!. we’re trying to design something better...
Actually that thing is reading a static file and creates a dictionary of it.... so another clone of something that we already have on a file and double in python... then better keep it somehow once and swig it.

It is already accessible from Python.



Re: One proc file for detecting the MACHINE in all enigma2 images. #200 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 2 August 2020 - 22:37

It is very relevant because your objection to branding module as the API is mainly based on that misconception.

 

 


That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.

 

They are two different things, model information won't show you what a model can do.

Actually it has the full range of static info, very similar to boxbranding.

https://github.com/o...info.bb#L23-L68




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users