LCD Display blank on some plugins

[twol]

Well clearly you understood my instructions well enough when you posted this: https://www.world-of-satellite.com/...-code-refactor&p=502462&viewfull=1#post502462

As you posted the screenshots yourself.

Anyway the numerical text input seems to be fixed now, I just tested on JMX and Xstreamity so thank you for that.

However the LCD issue remains (but that is off topic again), you can only test this on boxes with an LCD display such as Solo4K, Ultimo4K, Duo4K, Duo4K SE and some other models that have a proper LCD screen (I don't know the names and models of all the boxes).

Well the Giga4K‘s have a „proper“ LCD screen - and no issues there, so again its a Vu+ issue and you need to be specific

 

[Ev0]

Well the Giga4K‘s have a „proper“ LCD screen - and no issues there, so again its a Vu+ issue and you need to be specific

So on the Giga4K when you play a stream you have info on the lcd screen ?

 

[twol]

So on the Giga4K when you play a stream you have info on the lcd screen ?

Cannot answer if that works now, as I no longer have streams on my Giga4K‘s - will try and setup a stream and then test (unless you can supply a stream (if so pm me))

 

[Ev0]

Cannot answer if that works now, as I no longer have streams on my Giga4K‘s - will try and setup a stream and then test (unless you can supply a stream (if so pm me))

You have a PM

 

[ian1095]

I use ATV 6.4 and the display problem is evident on that too.

My 2 cents is that if a plugin uses it own player like xtreamity does then since the screens refactoring update the importing from infobargenerics no longer works.

Plugins usually use something similar to this to define options to show information in the display or on the plugins streamplayer infobar

from Screens.InfoBarGenerics import InfoBarSummarySupport, InfoBarMoviePlayerSummarySupport, InfoBarServiceNotifications, InfoBarSeek, InfoBarAudioSelection, InfoBarSubtitleSupport, InfoBarShowHide

and then simply add a class for the player using the above to init self

This used to work in xtreamity and all other plugins using their own player and the display used to show all the relevant info, that is until IanSav refactored the screens. Since then the display remains blank.

So has something be added in the refactoring that's not been subsequently added to infobargenerics, for plugins to then import ?

Anyway the fact remains that since IanSav's updates no one now has a working display with all OE-A based images when a plugin uses its own onboard player. If a plugin uses the E2 mediaplayer then the display works as it should.

Ian.

 

[ian1095]

OK so why can't the Screen Refactoring updates be reverted ? Was anything important gained by them ? Because they've broken plugins that have worked for donkeys years on all image types.

We are now in a position whereby if the fix is added then plugins will then only work correctly on OE-A based images, but if it isn't then they will only work correctly on none OE-A images. This is crazy.

 

[ccs]

.... i guess updating the plugins is out of the question? Seems a sensible approach to me.

 

[ian1095]

As stated, if the fix is added to the plugins ( all plugins using their own Onboard Player and there are loads ) then the plugins will only ever work on OE-A images and not all images as they used to.

 

[ccs]

As stated, if the fix is added to the plugins ( all plugins using their own Onboard Player and there are loads ) then the plugins will only ever work on OE-A images and not all images as they used to.

So are you saying the plugins can't be fixed, or won't be fixed?

 

[ian1095]

I'm saying that if they are, then they will no longer work on other images as well as OE-A images. I'm also saying that because these updates have broken so many ( all plugins using their own onboard player ) then given these two factors, its most unlikely they will be fixed

 

[abu baniaz]

The display skin code does not necessarily need reverting. A backward compatibility needs to be added. It should be possible. That way plugins using old code will still work and new plugins can use newer and better code.

 

[MaxMeyer]

Why is it out of the question to update the plug-ins? I think this is a reasonable action.

 

[Ev0]

Why is it out of the question to update the plug-ins? I think this is a reasonable action.

It was explained above, if (and it's a big if) all plugins were updated to work with the new code, then they would no longer work with ALL images, and instead only work with oe-a images (there are images that do not use oe-a code too).

Also ontop of that, you are expecting numerous plugin authors (some of which are no longer on the scene and some who may no longer be alive), to update various plugins to work correctly again with oe-a images, but break compatibility with other images, just because someone decided to change some code for no other reason, than because they could.

 

[ccs]

.... just because someone decided to change some code for no other reason, than because they could.

No wonder there are issues if you think that's the only reason.

 

[Ev0]

No wonder there are issues if you think that's the only reason.

Ok so why was it changed then, what great purpose was there to changing it and breaking functionality ?

As an end user, I see no difference other than the lcd no longer works.

 

[ccs]

Not sure if this is relevant.....

No I'm just referring to the broken display issue apparent since IanSav refactored the screens in all OE-A based images

taken from this link...

https://www.linuxsat-support.com/thread/142258-x-streamity-xtream-codes-iptv-player/?postID=578542#post578542

Accully since i do test lots of images and STBs i can tell you that this is not just an OE-A issue.
In my test about no image works as intended. Yes OE-A lcd turns black when LCD4Linux is installed.

Without LCD4Linux installed
Shows Audio and Video Icons and also Time.
Channelnames shows (....) and no progressbar.

Blackhole works but shows the channel name with full service ref and stream link.ts
DreamOS have same issus as OE-A but after installing plugin "DisplaySkin" instead of LCD4Linux
all works fine. Now for DreamOS i have the Dreambox Two UHD only as test for lcd so might work better on others like DM 900/920
Maybe some users of those boxes can give some feedback??

taken from this link...

https://www.linuxsat-support.com/thread/142258-x-streamity-xtream-codes-iptv-player/?postID=578587#post578587

 

[ian1095]

Not relevant.

DreamOS is closed source and has never worked without extra plugins being installed. This is their choice in their closed source image, but other LCD plugins have always been required to get anything more than just a basic LCD.

If someone can tell us the benefits gained from IsnSav's screen refactoring then fair enough, but as far as I can see all its achieved is to break functionality with many plugins that have worked perfectly for years using the old code and I cannot see any reason not to revert it back to how it was, unless there is something really beneficial to the operation of E2 thats not obviously apparent. As stated above, to me at least its just change for the sake of it. The old adage comes into play here " If it ain't broken then don't try to fix it" and this is exactly what's been done.

He claims its for efficiency and to simplify code tracing and management, but for whom ? if its for him then as he's now thrown his dummy out of his pram and is now refusing to perform anymore E2 development because end users have complained in many threads like this on many forums about these updates. So I ask again, what's the point of keeping this code and what are the benefits gained ? when it causes so many negative effects to end users and is now never going to be completed unless he agrees to return and fix the issues these changes have caused.

 

[abu baniaz]

There have always been difference between PLI and OEA screen code and was done in different places. Centralising it and making it in one place rather than placed across several pieces of code makes sense.

However, the best thing is to add in backward compatibility for changes made. It should be standard approach especially when variable names are changed. There are the odd occasions where it can't be done.

I can't say more otherwise I'll get accused of harassment and bullying.

 

[twol]

As the guy thats been converting OpenViX to python 3 over the last few months (.. and I guess you will be saying what the **** is that for? ... but unfortunately technology moves on and python 2 is stabilised) and has had to handle the numerous changes, we have ended up with better code, less code and simpler code compared to the often confused, broken (Yes in some areas incorrect code!) and totally undocumented mess that is Enigma2.
I realise that you don‘t like change, but unfortunately without change you die .... and if you think the current issues are big, wait until we are forced to python 3 and your favourite plugin no longer works, because the original provider no longer supports it. Of course you could actually do something worthwhile, learn python and perhaps help fix the issues yourself - you might understand then the reasons for these changes.

 

[ian1095]

I agree.

There's little point in bitching about this further and discussing cause and effect, because people begin to feel aggrieved and that they are being attacked personally as IanSav has done, when in actual fact they're not.
The fact remains that if someone now choses to use an OE-A based image, then they're not going to have a working display with any plugin that uses its own onboard player.
Surely this cannot be right and needs addressing ? regardless of what caused it and who's at fault.

ps I do know python.