2057 replies to this topic

[Huevos]

Info you don't have, empty string.

[Huevos]

For items that need a specific value, is there documentation available of what those should be? Fields like "brand", "

", "rcidnum", "timerwakeupmode", etc?

 

And what about data we don't have, like "imagedevbuild", "imgrevision"?

All those values are set in the metas. So for example let's look a vuultimo4k:

 

brand: https://github.com/o...e/vuplus.inc#L7

displaytype: https://github.com/o...hardware.inc#L7

rcidnum: https://github.com/o...ardware.inc#L54

timerwakeupmode: https://github.com/o...ardware.inc#L74

[Huevos]

https://github.com/O...mment-135228379

 

I have to agree with ims, overriding blink is wrong. It is a skin setting. PLi shouldn't be breaking skins like this. And who decides blinking makes users nervous? How was that surveyed?

 

Also for this stupid setting to take effect a restart is needed.

 

And it breaks display skins which now show no recording at all.

 

Really should be removed.

 

For me it doesn't make sense for the image to override what the skinner is trying to achieve.

Edited by Huevos, 18 December 2023 - 12:12.

[WanWizard]

All those values are set in the metas. So for example let's look a vuultimo4k:

 

brand: https://github.com/o...e/vuplus.inc#L7

displaytype: https://github.com/o...hardware.inc#L7

rcidnum: https://github.com/o...ardware.inc#L54

timerwakeupmode: https://github.com/o...ardware.inc#L74

 

 

Thanks,

 

I've asked Neo to look into the BSP changes, for us less simple than for OE-A.

 

The file is there now, all I need is to add as much info as possible from the build, and complete it at first boot in the image for data we don't have at build time.

[littlesat]

 PLi shouldn't be breaking skins like this. And who decides blinking makes users nervous? How was that surveyed?

 

At the time our standard skin was created this was a mandatory requirement not to do blinking. This is as simple as it is....  At that time you weren't involved in the discussions. Everyone here said we should not do blinking. And it is a well known knowledge... it takes attention and is simply making nervous. This is a fact....  I do not remember where the discussion was as it could also be an internal discussion. But I have on my notes from the skin I designed >10 years ago that all blinking should be out... Of course we can decide differently. But actually this e2os skin looks simple, easy and nice... and based on that old rule, blinking still add nervous stuff to it. A simple red REC icon does also do the job... Most likely you just to get used to it that it does not blink anymore. As it is RED with white it already gives sufficient attention...

 

It is indeed kind of obvious that you cannot change it instantly. But that is because of the connect downstream stuff I purpose.

 

That a restart is mandatory is as far I can see only the way how it is implemented. At the place where the real on/off stuff of the blinking is done is a better location. To make differences for displays (LCDs) and the skin on the screen and if you want to make it configurable it would be nice the skin has an additional parameter attribute that identifies that the blinking could be conditional.

 

Over the years and years as our standard skin never did blink I never missed it and therefore now 'm also convinced it is much better to avoid that nervous blinking at screens...  Maybe you should try as the 'blindly' standard is blink blink blink blink blinking recording icons... 

 

Regarding the enigma.info file it might be better, but I'm afraid we are too late to do something with eval in python... so you can also do things like =bool(True) or so... so the variable types were clearly defined....

Edited by littlesat, 18 December 2023 - 14:32.

[littlesat]

Regarding the boxinfo... some of them get in there at runtime... and systeminfo variables are also available via the global class.

When the file does not need to be complete this can be done this way... and when the systeminfo has a different parameter string... we get in another work-a-round...

[WanWizard]

Where ever possible I am going to remove all that runtime code in SystemInfo and replace it by a call to the boxinfo class.

 

No need to add or maintain workarounds, and no need or reason to do it different from other images. The main idea of doing this externally is dat the data is also available outside E2.

 

There are only a few items I need to update at first boot, for the 1:N type images ( for example, we won't know if the box is a H9S or a H9T or a H9Twin before we boot the image ).

[WanWizard]

Regarding the enigma.info file it might be better, but I'm afraid we are too late to do something with eval in python... so you can also do things like =bool(True) or so... so the variable types were clearly defined....

 

Like Huevos said, we had the chance for years, and I tried, but nobody at OpenPLi could be bothered. The world moved on, and the time for input has now passed.

[neo]

@Huevos,

 

I'm busy helping WanWizard with the BSP side of things, and I wonder, where does MACHINEBUILD come from in an OE-A image?

 

For example, if I want to build an image for the Amiko Viper Combo HDD, and use MACHINE=vipercombohdd, somewhere there must be a translation to one of the entwopia oem machines that is actually build.

 

Where can I find that? I need that to copy the correct MACHINE_FEATURES and other machine specific values...

 

edit: forget it, found the mapping in the build-environment repo...

Edited by neo, 18 December 2023 - 14:38.

[littlesat]

and the time for input has now passed.

 

Yes some of the input from my side get's in... like the checksum that isn't even parsed. But the input about the location and the warning about the variable types were ignored. It was indeed waiting for more input but some lost patience and again we get something that lacks proper development. Time goes on....but to do something good with divided meanings may take a longer time. The biggest pain is because the others cannot wait, while I at that moment was not able to really contribute. Sometimes good things take longer...

 

FYI https://forums.openp...e-38?hl=boxinfo

Edited by littlesat, 18 December 2023 - 14:55.

[littlesat]

I just reverted the blinking config... as it does not really work properly. The discussion if a rec icon should blink yes/no is a different discussion... let's brainstorm about it again after 10 years...

Edited by littlesat, 18 December 2023 - 14:47.

[mrvica]

What I am missing is the PrimeTime line in channel selection (20:15), just after those 3 lines for the next events

Edited by mrvica, 18 December 2023 - 15:16.

[littlesat]

That was never there I'm afraid... but in our standard skin we had 4 positions here. I don't remember if our standard skin also could show primetime there... (unless this is not a real added value in my point of view....)

[Huevos]

 

and the time for input has now passed.

 

Yes some of the input from my side get's in... like the checksum that isn't even parsed. But the input about the location and the warning about the variable types were ignored. It was indeed waiting for more input but some lost patience and again we get something that lacks proper development. Time goes on....but to do something good with divided meanings may take a longer time. The biggest pain is because the others cannot wait, while I at that moment was not able to really contribute. Sometimes good things take longer...

 

FYI https://forums.openp...e-38?hl=boxinfo

 

The checksum is processed in OpenATV code. In OpenViX it is skipped this.

 

As far as I know the checksum was added at IanSav's request because he didn't want users to be able to modify that file.

 

For the BoxInfo stuff I think we should open a new thread.

[mrvica]

we had already similar Thread

One proc file for detecting the MACHINE in all enigma2 images. - [EN] Third-Party Development - Forums (openpli.org)

[littlesat]

Yes these were the ideas... and after all it was not even our colleagues from OpenVix who did lost patience. It was at that time as far I can see our colleagues from OpenVision. Unless this I still hope together we can slightly improve it.

The way the file is parsed with the exceptions and the big if then else and how Booleans are parsed does not give me a real good feeling. I hope you agree and I also hope we can find a way to improve this somehow (afterwards)... We still have different images and beside multiboot they do not need all in common (for multiboot we're already add the required stuff - so we could now also consider to parse these).

Edited by littlesat, 18 December 2023 - 16:17.

[mrvica]

That was never there I'm afraid... but in our standard skin we had 4 positions here. I don't remember if our standard skin also could show primetime there... (unless this is not a real added value in my point of view....)

we can do it via config

- show four next events in channel selection

- show three next events and prime time

[littlesat]

Via config is a thing that should be done with care.

[mrvica]

I don't remember if our standard skin also could show primetime there... (unless this is not a real added value in my point of view....)

the prime time code is in GraphMultiEpg present

enigma2/lib/python/Plugins/Extensions/GraphMultiEPG/GraphMultiEpg.py at develop · OpenPLi/enigma2 · GitHub

[littlesat]

But it was as far I know never in the channel selection screen.