The thing is we have plugins, so why add more? That is my question.
xDreamy appears to be assembled and edited using Qodo. There is nothing wrong with that, but there also appears to be a lot of copy and pasting in the file edits which can lead to loose ends. Then there are files and other items just left behind that should not be included in an .ipk file including a .bak or backup file. There were also many different version numbers in the code at various places which at minimum is just not a good idea.
Examining the code by disassembling the .ipk file gives the perception that problems existed but were coded over. Things kept getting added without ever solving all of the existing problems. The plugin.py file is huge and should really be broken into 3 to 4 files as doing this would make it lots easier on the AI coder, plus it would improve the performance of the AI coder. In general, an AI coder is not going to read 3 or 4 thousand lines of code for every edit, which means some areas of the large plugin.py are either never seen or are ignored. This can lead to all sorts of coding errors.
It is also extremely easy to expand a project beyond a point of usefulness as I have done that several times when coding with AI. For me, some of it was just pure excitement at seeing something working, and at other times, the AI offers helpful hints, such as: "want me to add this?"
Overall, I think the xDreamy skin is a very good piece of work, but at some point you should ask yourself if you are building a skin or an image? All of our FTA receivers are at least 10 years old in technology with some stretching out to around 15-20 years in technology. A FTA receiver kernel of 4.x.x is considered new. Our receivers were based and built for what was available when the receivers were produced. Not for what would be available a decade or two later.
Some receivers now are having space problems, which means consideration should be given to how much "bloat" we put in a plugin. My definition of bloat is something that is useful, but is of no use to the owner or user of the receiver. The space and resources we have available in a given receiver model were based on the smaller images of 10-15 years ago.
Attached are the changes that were made, and also the plugin that was created after the changes. You are welcome to keep these changes or discard them. The idea is to give suggestions. Not to say that it has to be done this way or like this. The plugin.py file is where the work should be focused. There are 74 broad except Exception: blocks. Then you have One of the seventeen URLs (Transmission) is plain http://, not https:// ... meaning that specific download has no encryption at all. Anyone positioned on the network between the receiver and dreambox4u.com (a compromised Wi-Fi hotspot, a hijacked DNS entry, a stale/expired domain later bought by someone else) could swap in a malicious script, and the receiver would run it as root without any way to notice.
Even the sixteen https:// ones fetch third-party scripts the xDreamy author doesn't control (various personal GitHub/GitLab repos) and run them unmodified if any of those repos is ever compromised, this becomes a code-execution path onto your box. Does a skin really need all of this? Is it useful to everyone? Just something to think about.