Gigablue Quad 4K & UE 4K
.........FBC Tuners:
------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
.......................> FBC & DVB-S2X into 90cm dish (27.5W) Opticum robust Unicable LNB
AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
Zgemma H9 C/S into Giga4K
Gigablue Quad 4K & UE 4K
.........FBC Tuners:
------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
.......................> FBC & DVB-S2X into 90cm dish (27.5W) Opticum robust Unicable LNB
AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
Zgemma H9 C/S into Giga4K
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
and then simply add a class for the player using the above to init selfCode:from Screens.InfoBarGenerics import InfoBarSummarySupport, InfoBarMoviePlayerSummarySupport, InfoBarServiceNotifications, InfoBarSeek, InfoBarAudioSelection, InfoBarSubtitleSupport, InfoBarShowHide
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.
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.
Last edited by ian1095; 25-10-20 at 15:32.
.... i guess updating the plugins is out of the question? Seems a sensible approach to me.
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.
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
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.
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.