1894 replies to this topic

[littlesat]

Merged…
And again sorry for challenging this… and thanks for you patience and motivation.
I hope next week I can create a simple second infobar for you.
In addition these actions will make stuff more compatible with reasonable good coding structure.

Edited by littlesat, 9 December 2023 - 13:23.

[littlesat]

Maybe consider to rename vaudioinfo.py to avinfo.py or videoaudioinfo.py…. But it will break skins of course. Actually bad naming….’but I know I did the same with pliextrainfo.py years ago… so not mandatory, just a remark and if possible then please…

Edited by littlesat, 9 December 2023 - 13:28.

[Huevos]

For the box icons you can make a renderer that checks if a box specific picture is available and then show this one instead of the standard one…. And then make a ipk that makes them downloadable.
Then they can be added in the bsp or an ipk could be added in a box specific 3rd party feed. Or we just build them and but the right ones in there during the build process.

This approach is wrong. The build can add an svg image in /usr/share/enigma2 called boxlogo.svg. The skin can display that logo. It will be put there by the build so will always be the correct logo. No need for converters. This is just the same as loading the correct rc.png in each box.

[Pr2]

Hi,

 

First thanks Dimitar to change into consideration my previous remarks, the DVB-C logo is better now.

 

I found something else that annoy me:

- When performing an update in the default skin I have the number of packages that will be updated (and I'd like to have this information).

With your skin, we have a full screen when the opkg update is running and then it turns into a center screen with the different options.

I no longer see the number of packages that will be updated.

Moreover, when there are too many package to update, OpenPLi warms that it is better to flash the image rather than try an online package update. I fear that this warning will be lost in the current skin.

 

Another point, the main menu is too small (not wide enough).

Some words are much longer in other languages than in english example:  "setup" is 5 letters but must be translate into "configuration" (in french) which is 13 letters  so the translation for "Setup remote tuner" will become "Configuration du récepteur distant" and it is truncated on screen with "Configuration du récepteur"  but this totally change the meaning which became then "setup tuner".

So the menus became confusing for end-users.

 

So I really think that either:

- the menu should take more space on screen (at least 1,5 * larger)

- retrieve the longest translation string and adjust the screen width accordingly.

 

I am a big fan of picon so I try to have picon for every channels.

 

Some image provide the opportunity to have picon for the favorites too, and I was suprised to see that OpenPLi support it too but the picon is only displayed closed to the PiG in the channel list.

Do you think to have the userbouquet picon on the left to the name (like we have in the channel list) in place of the folder icon which is display for every favourite?

[Huevos]

Hi,Moreover, when there are too many package to update, OpenPLi warms that it is better to flash the image rather than try an online package update. I fear that this warning will be lost in the current skin.

So my question is what is this stupid warning for? And don't get me wrong it is in other images too, but why? If I update Ubuntu or Windows and there are 300 packages to upgrade it doesn't tell me to reload the operating system so why at some point in the past has someone decided it is necessary here? Unless there is some kind of OPKG conflict that can't be fixed (same as in Ubuntu) why is it necessary to reflash? And why is 99 packages considered safe and 100 not?

[WanWizard]

First of all, the number of packages is arbitrary, the number it is a value plucked out of thin air. We warn at 100, we block at 150 (if memory serves me right).

 

There are several reasons for this warning:

• The dependency system in OE sucks big time, especially in relation to busybox provided components
• opkg can process in parallel, which makes dependencies worse as it doesn't take the proper sequence of pre- and post- scripts into account
• opkg downloads in parallel, and downloading lots of packages requires lots of free flash space, especially an issue on older boxes

Better package systems like rpm and apt are more feature rich. and much better at dealing with these issues, and furthermore, full linux distro's don't have to deal with busybox dependencies.

 

The problem with busybox is that if that is updated, 99% of all general linux commands disappear. I tried to work around this here: https://github.com/O...gma2.sh.in#L115 which made updating from E2 more stable.

 

There are some hacks in OE in place to work around this, which copy the busybox binary to /tmp, create links for some tools, and update the path, but that is far from complete and full proof.
 

It is also about mindset. There are still lots of people doing an "opkg update && opkg upgrade" from the commandline. Which can absolutely wreck your box if that includes busybox (there are other packages with similar issues).These warnings serve as a reminder not to do such things.

 

As to dependencies in scripts, if you update a, b and c in one go, it will execute the prerm scripts first, for all tree, then removes all three, then runs the postrm scripts for all three. Which is a disaster if there is a dependency between them. You can see this behaviour clearly if you update on the commandline, you get a lot of "configure" messages at the end, long after the packages have been updated. Which means there is time between the installation of the new package, and the files of package being properly available, during this time, any other packages that require those files may fail.

 

The opkg issue also links into the problem OE-A created by installing everything but the kitchensink as standard, so you have separate binaries instead of busybox links, in combination with the habbit of manually creating ipk's containing scripts assuming that all commands are always there. It creates a very instable environment.

 

So in short, it was introduced to avoid people, especially the 99..9999% of OpenPLi users that are simple end-users, from "bricking" their box.

[Huevos]

@WanWizard, do we install everything but the kitchen sink? Can you please give some examples of things that are in our base image that you believe should not be?

[littlesat]

At least by openatv I now the images are twice as big than ours because of that…. I need to give any example. And also openvix is bigger.

Edited by littlesat, 10 December 2023 - 00:04.

[WanWizard]

@WanWizard, do we install everything but the kitchen sink? Can you please give some examples of things that are in our base image that you believe should not be?

 

That is true for most "full fat" packages, from bash to all sorts of tools. Same with all sorts of python packages. On OpenPLi, nothing is pre installed, everything that is in the base image is there because of a dependency.

 

The point is it makes people lazy, 99.99% of the people complaining here about dependency issues have downloaded an ipk created "the OE-A way", without the correct dependencies because "everything" is installed by default anyway. Just look at all the missing "python3-requests" reports here...

[Huevos]

So, I can't think which unnecessary pre-loaded modules you are talking about. Can you be specific? And which packages on OE-A have incorrect dependencies?

[WanWizard]

I didn't write that OE-A packages are having incorrect dependencies.

 

I wrote that they (ATV before OE-A even) advocate creating ipk's manually instead of via a build process. The internet is littered with them.

 

And most of them have an incomplete control file, due to the assumption that all dependencies will be preinstalled anyway. I gave python-request / python3-request as an example, which is not present in the default OpenPLi image.

 

People download them, install them on OpenPLi, and then come here to complain they don't work.

[Frenske]

Shouldn’t we split these last discussion regarding additional packages from this skin related topic?

[DimitarCC]

Yes that have to be separated.

[DimitarCC]

Regarding the skin and latest modifications that comes with it (c++ and python)....

I have understood there was issues report in private forum that i have no access to...

Hope that was resolved.

 

But is not really correct that to be only reported in private forum without author knowledge. At least somebody could post them here....

 

Otherwise skin seems to be complete without some PLi specific screens that are still not skinned...

Also the reports that @pr2 has report about missing count of packages...(it also PLi specific)

 

Regarding the main menu and not fitting entries... Well i wish to not make it wider since will ruin the design.

So another solution have to be developed for that. I accept any suggestions how to handle that.

Edited by DimitarCC, 11 December 2023 - 17:08.

[littlesat]

I think you should be invited to that private part.... But please be aware that also I did not heard any communication in the private part...?

 

One thing are the dots... and the hidden (number markers).... that 'overcounts' pages in the channelselector... at least I speculate that this is the reason why in the channel list this is not going right yet.

 

And as far i can see everything was merged....

Edited by littlesat, 11 December 2023 - 18:11.

[DimitarCC]

I do not know much details...
I know it was an exceptions for missing function in SWIG...
Anyway if not more reports then it is resolved...
About number markers... I guess more cpp extensions have to be made so to get correct count

Edited by DimitarCC, 11 December 2023 - 19:16.

[littlesat]

Afterwards I have non idea this is about. As far I know the counts are also fine.

[DimitarCC]

Counts are fine but number markers are hidden and pager doesnt know the correct visible count. So that have to be extended and correct count provide.

[Huevos]

Shouldn’t we split these last discussion regarding additional packages from this skin related topic?

No, it is also related to this skin.

 

https://github.com/D...b/main/build.sh

[littlesat]

I think this is not related to this skin.

Edited by littlesat, 11 December 2023 - 22:39.