2022 replies to this topic

[Huevos]

I warned them about that: if values are used as data in the image, its value (range) and type needs to be exactly defined.

 

A "display" value was said at the time to be for display purposes only, so you shouldn't use it in code...

So it was me that said that (maybe too soon). The problem is "displaybrand" contains "Zgemma" and "brand" contains "Air-Digital". So we do need "displaybrand" for the brand logo.

Edited by Huevos, 19 December 2023 - 20:04.

[Abu Baniaz]

For the capitalisation issue, can we not just treat them as lower before processing the value? Hopefully differences can be resolved.

[littlesat]

Or maybe first letter capitalized and the rest lower case… at least for parsing SVGs or pngs

[Huevos]

Or maybe first letter capitalized and the rest lower case… at least for parsing SVGs or pngs

The capitalization in OE-A is already set. Abu's point was that doesn't matter if we do comparison against lower.

[Abu Baniaz]

So it was me that said that (maybe too soon). The problem is "displaybrand" contains "Zgemma" and "brand" contains "Air-Digital". So we do need "displaybrand" for the brand logo.

 

I think the `display` part  was chosen as that is what is `dispalyed` to the enduser. The Airdigital one is straightforward, but the Dags ones have multiple brands. I suppose think of Vauxhall and Opel

[WanWizard]

So it was me that said that (maybe too soon). The problem is "displaybrand" contains "Zgemma" and "brand" contains "Air-Digital". So we do need "displaybrand" for the brand logo.

 

Only because there was no thought given to the fact one might need a normalized brand name in the code.

 

There is simply no consistancy at all when it comes to brands. I've looked through the info files currently generated on the buildserver, it is one big mess.

 

I think the `display` part  was chosen as that is what is `dispalyed` to the enduser. The Airdigital one is straightforward, but the Dags ones have multiple brands. I suppose think of Vauxhall and Opel

 

Dags is defined as an OEM brand. But nextv isn't. And the gbtrio4k, sf8008 and ustym4kpro are also the same OEM brand box, but are defined 3 times as original brand in OE-A.

 

The point is that if there is a need to have access to the "Retail brand" in code, there should be a normalized value in the enigma.info file:

oembrand=dags
retailbrand=qviart
displaybrand=Qviart

where displaybrand is a random value string, for display purposes only.

[neo]

I've fixed the reported issues, and changed displaybrand for VU+ to Vu+, pending the discussion above.

[DimitarCC]

 

Dags is defined as an OEM brand. But nextv isn't. And the gbtrio4k, sf8008 and ustym4kpro are also the same OEM brand box, but are defined 3 times as original brand in OE-A.

 

 

 I got kind of confused here. About brands gbtrio4k is Gigablue, sf8008 is Octagon and ustym4kpro is UClan. So brands are not the same. As hardware they might be similar and even the maker can be the same but the market brands are different...

Maybe thats why it is split like that 

[WanWizard]

In OE-A speak, there are brands that make boxes (OEM brands) and brands that sell boxes (Retail brands), and sometimes, they are the same. It would have been better to speak about Manufacturer and Retailer.

 

The Gigablue gbtrio4k, Octagon sf8008 and UClan ustym4kpro are box models from Retail brands. They are however all identical, and all made by the same OEM brand (manufacturer).

 

Sometimes, OE-A defines them as such, Dags being a prime example. Dags is a manufacturer, but doesn't retail. Dags OEM hardware is sold by amongst others Qviart and Xsarius. But also Technomate, Iqonios, Optimus, Mediabox, Roxxs, Force2, etc...

 

So in the OE-A build tree, you have a mapping between the two, so if you for example build for the Qviart Lunix4k, you actually build the mapped dags image, with Qviart Lunix4k branding,

 

But on the other hand Nextv is also an OEM manufacturer that doesn't retail. It makes for example the Octagon SF4008 (which defines incorrectly octagon as OEM_BRAND), the Xtrend ET7000 and ET11000 (also retailed by brands like Galaxy Innovations). But according to OE-A, the OEM_Brand is xtrend, which hasn't made any hardware in many, many years, they went bust after the release of the ET10000, and Nextv is de holder of the "Xtrend" brand.

 

Then off course you have Manufacturers that also retail, like Air-Digital (uses the brand Zgemma) and VU+..

 

And to make it even more complex, the Zgemma H7 is identical to the Vimastec VS1500, but OE-A labels the VS1500 as made by OEM manufacturer "gfutures", whiile the Zgemma is appearently made by "air-digital".

 

Hence my remark that it is confusing and far from consistent.

[WanWizard]

As to the display info, there are values in the enigma.info file that are for processing (they should have a strict definition as to type and contents) and for display (which are all string, free-form, its value can not be relied upon).

[DimitarCC]

Where there is working develop build maybe have to consider to add the logos repo to build and install together with the skin....

[littlesat]

The strict type and definition topic was one of my observations. You also see in the renderer code that this was also a struggle there. At least forcing to string is resolved in the definition and I have already something that simplify the struggling. I hope I can make that change suggestion. But there is one other restriction where some stuff is forced to string which may become float. That’s release version stuff. I understand at least vix make it string, but is that part done because openatv does not do that? So for multiboot something can go wrong? Isn’t there just parse it as float and convert it where it is read/used in multiboot to change it back there to string? Or just show the float. This might remove an additional work-a-round in this rendering code?

[littlesat]

The skin should not crash when logo’s are not there… but I already understand you agreed. Indeed logo’s should follow. I have no idea but I think we need only the logo’s for a specific box and not all for all boxes.
I also prefer to have the renderers in the image.

Edited by littlesat, 21 December 2023 - 08:06.

[DimitarCC]

Yes. The logos installed on the particular box are only boxlogo, brandlogo and distrologo.

 

In previous posts @Huevos post a example recipe that is in use in ViX now. And the logos package is as depends for the skin now.

 

But it can be moved.

 

As for the crashes. Hope that is resolved in the changeset https://github.com/D...8efe7a9c533ef59

[littlesat]

Thanks…
Getting the logo’s is something we need help from wanwizard. They are now busy with the boxinfo stuff.
I see the boxinfo.py is currently the only leftover…

Edited by littlesat, 21 December 2023 - 10:08.

[DimitarCC]

yes it is the only one now that is left in the skin as python code.

[DimitarCC]

So that is removed from the skin now...

It will be provided by enigma2-boxlogos package together with the logos that this renderer is for.

[littlesat]

Wonderfull!!!! Thanks for the understanding and work somehow together!!!

@Wanwizard... could we 'share' that boxlogos package?

Edited by littlesat, 21 December 2023 - 12:47.

[WanWizard]

I'm personally still of the opinion that skin related files and skin related code should be part of the skin and not of the base image, but appearently I am alone in that.

 

I haven't followed the discussion, currently helping Neo with test builds. So if someone else can have a look at it? @Tech?

[DimitarCC]

It is in my repo here https://github.com/D...rCC/e2-boxlogos

 

you just need a recipe and to respect output file names