772 replies to this topic

[Persian Prince]

Yeah but

 

That really hurts..... if box in (a,b,c,d,e,f,g) or model in (q,r,s) then do y all over the place...  And then for DMM a separate py file...  And here it does not stop... I see also things like when tuner in slot x then give message it does not work... and then also do blingscan except when tuner has type z then use different binary...

 

Actually the situation from this blindscan stuff was something the community should not except in the first place! This is THE example how it should not be done. And the most mean thing here is that it might now be too late to fix it!

 

At the end the users might have blindscan support on a lot of boxes. But the DEVs and maintenance of the plugin may become a nightmare. I suggest this is out-of-balance!

Yeah but I think it's better than https://github.com/O...e8e6b31efd2abbf

[MCelliotG]

Let me chime in in the blindscan situation...

The way hardware blindscan is treated in the plugin is simply atrocious.

What separates DMM is that there is no blindscan binary because the drivers return true in this part of the code

def BlindscanMain(session, close=None, **kwargs):
	have_Support_Blindscan = False
	try:
		if 'Supports_Blind_Scan: yes' in open('/proc/bus/nim_sockets').read():
			have_Support_Blindscan = True
	except:
		pass
	if have_Support_Blindscan:
		import dmmBlindScan
		session.openWithCallback(boundFunction(BlindscanCallback, close), dmmBlindScan.DmmBlindscan)
	else:
		session.openWithCallback(boundFunction(BlindscanCallback, close), Blindscan)

Which opens up a whole new different blindscan plugin with fewer options and bad blindscan results, no filters, very poor configurations etc.

This also affects HD51 since gfutures introduced have_Support_Blindscan = True in the Silabs driver, strategically not used in other STBs with Silabs such as SF8008.

This separation is very bad and unfair, all blindscan methods should use the same options.

Edited by MCelliotG, 21 July 2020 - 12:14.

[littlesat]

Indeed all blindscan options should do the same.....

[IanSav]

Hi,

 

There seems to be some comment about developer support for Enigma2 images.

 

One of the recent frustrations in new code development is the fact that hardware developers seem to want to keep the codes that their remote control drivers emit into Enigma2 a secret.  This is ridiculous!  All manufacturers should be expected, demanded, to document exactly what every button on their remote control emit, as a KEY_xxx code, into Enigma2.  It should not be up to Enigma2 developers and support people to scramble to find access to *EVERY* box and to painstakingly work out and document the button codes so that the hardware can be supported by their image.  Similarly any special modes like SHIFT buttons or any buttons that change they codes need to be properly documented.

 

Further, if the drivers are to be provided as a closed source binary then it should be demanded that the manufacturers *must* allow a button translation may be enabled for all their remote control (and front panel) drivers.  That is, Enigma2 developers should be able to adjust the KEY_xxx codes for every button on the remote control and front panel so that the Enigma2 firmware can be simplified and optimised.  The current need to bloat the key maps and action maps to make all the different remote controls work should be seen as inappropriate and wrong.  This will also formally allow firmware developers to reassign buttons to better support Enigma2.  For example, I would dearly love my GigaBlue UE 4K to remap the physical F1 button to emit the KEY_HELP code.  This remote control doesn't have a HELP button at all which very much damages the Enigma2 usage experience.  I think there are many examples where productive use could be made of uniformly enabling button remaps.

 

For example, to enable button remapping all the drivers should be made to have two mandatory function calls.  One should deliver a list of integers that are the KEY_xxx codes for that remote control presented in a documented order, probably top left to bottom right.  The other function call should be take an appropriate list of KEY_xxx codes and load that into the driver.  From that point any button press on the remote control should only emit the KEY_xxx code as requested by the firmware.

 

It may be difficult for the remote control driver to keep the updated list across firmware restarts but then it would be very easy (I have already prepared code) to load the driver remap data on Enigma2 startup.

 

So, if hardware manufacturers really do want to support the images and the developers let them start with this relatively simple request.

 

If this question is too far off topic I am happy for this post to be deleted.

 

Regards,

Ian.

[Abu Baniaz]

For example, I would dearly love my GigaBlue UE 4K to remap the physical F1 button to emit the KEY_HELP code.  This remote control doesn't have a HELP button at all which very much damages the Enigma2 usage experience.  I think there are many examples where productive use could be made of uniformly enabling button remaps.

This was added here:
https://github.com/O...5c2945039de3f03

ATV also has the functionality with the same mapping. A pull request to add this to ViX was submitted but rejected.
 

If this question is too far off topic I am happy for this post to be deleted.

Maybe moved to its own thread instead?

Edited by Abu Baniaz, 21 July 2020 - 14:36.

[IanSav]

Hi,

 

Those changes are hacks and not optimal.  They were appropriately rejected from OpenViX.  While Prl finishes the new help code we have also been workshopping an improved format of the rcpositions.xml file that will more appropriately address the issue of button remapping without needing various hacks across the firmware.

 

Here are a sample sample lines from the new rcpositions.xml file format for the new GigaBlue gb4 remote control:

<button keyid="KEY_PLAYPAUSE" name="PLAYPAUSE" title="Play / Pause" pos="57,388" shape="rect" size="28,12" />
<button keyid="KEY_FASTFORWARD" name="FASTFORWARD" title="Fast Forward" pos="88,388" shape="rect" size="28,12" />
<button keyid="KEY_F1" remap="KEY_HELP" name="F1" title="F1" pos="26,409" shape="rect" size="28,12" />
<button keyid="KEY_LIST" name="PLAYLIST" title="Play List" pos="57,409" shape="rect" size="28,12" />

Note that the F1 button has a quick and easy remap option that is local to the specific definition of the remote control.  If this code is processed there will be no need to adjust any Python code or key mappings to enable the F1 button as a HELP function.

 

Regards,

Ian.

Edited by IanSav, 21 July 2020 - 14:54.

[Abu Baniaz]

Yes, everybody hacks. there is only one person who knows how to code. Nonetheless, it is code that has been in PLI since 18 December 2015

 

On Pli and ATV,  the option button works as Help on the GB UE 4K remote.

[Huevos]

This is how I did it for Blindscan: https://github.com/O...ac60cb98404f247

 

Waiting to see the test reports.

LOL, just shows you can't select the binary in branding because your version still requires branding module to discover box brand. And the rest of the commit is just variable swapping and wasting RAM.

[Huevos]

Let me chime in in the blindscan situation...

The way hardware blindscan is treated in the plugin is simply atrocious.

What separates DMM is that there is no blindscan binary because the drivers return true in this part of the code

def BlindscanMain(session, close=None, **kwargs):
	have_Support_Blindscan = False
	try:
		if 'Supports_Blind_Scan: yes' in open('/proc/bus/nim_sockets').read():
			have_Support_Blindscan = True
	except:
		pass
	if have_Support_Blindscan:
		import dmmBlindScan
		session.openWithCallback(boundFunction(BlindscanCallback, close), dmmBlindScan.DmmBlindscan)
	else:
		session.openWithCallback(boundFunction(BlindscanCallback, close), Blindscan)

Which opens up a whole new different blindscan plugin with fewer options and bad blindscan results, no filters, very poor configurations etc.

This also affects HD51 since gfutures introduced have_Support_Blindscan = True in the Silabs driver, strategically not used in other STBs with Silabs such as SF8008.

This separation is very bad and unfair, all blindscan methods should use the same options.

Yes, the DMM add-on is crap. Should never have been added. Nor should the USB rubbish have been added.

 

As the person that wrote the plugin into its current form (filters, C-band, Ka-band, etc) it is very depressing to see how this lovely plugin has been hacked and vandalized (in a bid to support hardware that is not related to it in any way).

[Huevos]

Yes, [...]  it is code that has been in PLI since 18 December 2015

Does that make it less of a dirty hack?

[Abu Baniaz]

Wow, not only is it a dirty hack. Would be nice to see a definitive list of these definitions.

 

Fact remains that all remotes are different, some do not have lots of buttons and some send the wrong code. Some images work around it by implementing changes in configure.ac and some have the "hack/dirty hack" as you put it.

[Huevos]

Wow, not only is it a dirty hack. Would be nice to see a definitive list of these definitions.

 

Fact remains that all remotes are different, some do not have lots of buttons and some send the wrong code. Some images work around it by implementing changes in configure.ac and some have the "hack/dirty hack" as you put it.

I am merely stating that just because something has been in PLi repo for 5 years doesn't mean it can't be a dirty hack.

[Abu Baniaz]

 

Wow, not only is it a dirty hack. Would be nice to see a definitive list of these definitions.

 

Fact remains that all remotes are different, some do not have lots of buttons and some send the wrong code. Some images work around it by implementing changes in configure.ac and some have the "hack/dirty hack" as you put it.

I am merely stating that just because something has been in PLi repo for 5 years doesn't mean it can't be a dirty hack.

 

So one person calls it a hack, another calls it a dirty hack while the senior developers OF PLi added it and have not commented on it as being a hack. Can you be so kind as to give a definitive list of the various hacks so that our knowledge increases?

 

And also, is their a definition of acceptable hacks and what the tolerance levels are for these? For example, the Vu remotes have a modification for Info/EPG, is this a hack or not? Do we on one side say, lets adapt things so end users benefit because the manufacturer's don't care and on the other side say, it is a hack, we won't do that.

 

I very much look forward to learning about these definitions of hacks.

[Persian Prince]

 

 

Wow, not only is it a dirty hack. Would be nice to see a definitive list of these definitions.

 

Fact remains that all remotes are different, some do not have lots of buttons and some send the wrong code. Some images work around it by implementing changes in configure.ac and some have the "hack/dirty hack" as you put it.

I am merely stating that just because something has been in PLi repo for 5 years doesn't mean it can't be a dirty hack.

 

So one person calls it a hack, another calls it a dirty hack while the senior developers OF PLi added it and have not commented on it as being a hack. Can you be so kind as to give a definitive list of the various hacks so that our knowledge increases?

 

And also, is their a definition of acceptable hacks and what the tolerance levels are for these? For example, the Vu remotes have a modification for Info/EPG, is this a hack or not? Do we on one side say, lets adapt things so end users benefit because the manufacturer's don't care and on the other side say, it is a hack, we won't do that.

 

I very much look forward to learning about these definitions of hacks.

 

Don't get me wrong but I like your sense of humour

 

Even branding module or any other similar solution is helping manufacturers to not provide universal and standard things.

 

Hey x company you could change all the standards because we have another thing to deal with your crap outside enigma2 so cheers.

 

It's good to decide where we want to deal with these kind of data, inside enigma2 or outside it then get over it once for all.

 

Some companies are gone forever so there's no chance to change anything in hardware drivers.

[WanWizard]

We have to be honest about this.

 

Only a select few are actually manufacturers, all others are distributors that simply order a pallet of branded boxes from "ali".  

 

All of them are focused on getting the maximum profit from the minimum of investment, and only a select few have (some form of) interest in brand value and customer service.

 

Only a select few have a driver developer worth his or her salt you can talk to to get things done.

 

I personally would prefer to have this developer fix bugs or add / improve features. The recent changes to multiboot for a few vendors has shown how complex it is to make change happen, on both sides of the E2 fence.

 

So don't expect anything from the vendors on this topic, and I suggest we don't even ask. Let's design a proper abstraction layer that works for the different image builders, and move on.

[Huevos]

 

 

Wow, not only is it a dirty hack. Would be nice to see a definitive list of these definitions.

 

Fact remains that all remotes are different, some do not have lots of buttons and some send the wrong code. Some images work around it by implementing changes in configure.ac and some have the "hack/dirty hack" as you put it.

I am merely stating that just because something has been in PLi repo for 5 years doesn't mean it can't be a dirty hack.

 

So one person calls it a hack, another calls it a dirty hack while the senior developers OF PLi added it and have not commented on it as being a hack. Can you be so kind as to give a definitive list of the various hacks so that our knowledge increases?

 

And also, is their a definition of acceptable hacks and what the tolerance levels are for these? For example, the Vu remotes have a modification for Info/EPG, is this a hack or not? Do we on one side say, lets adapt things so end users benefit because the manufacturer's don't care and on the other side say, it is a hack, we won't do that.

 

I very much look forward to learning about these definitions of hacks.

 

Not sure if you are serious or on a wind up. A hack is either knowing or unknowingly "fixing" something in the wrong place or wrong way. Here is an example...

https://github.com/H...4dd10852159a832

 

In the case of the GB it is not reassigning the button that is the hack, but the crap way it has been done.

 

Vu could also be done in a much cleaner way from a coding point of view. On the Vu the INFO button is re-assigned to open the EPG. Even worse is the INFO button has EPG printed on the button. End result is because the INFO button is reassigned to EPG it means on Vu hardware it is impossible to access the screen that corresponds with the INFO button. So in this case it was a conscious decision to deny users of the screen accessed from the INFO button in InfoBarGenerics.py.

[littlesat]

The joynescsn hack indeed... e2 takes the while service ref as key while it should only take the mandatory fields as key... and not include ‘parameter’ fields......! And. Indeed the vu info button.... here the biggest issue is the community accepted it.

Edited by littlesat, 22 July 2020 - 06:19.

[IanSav]

Hi,

 

This is an example of my definition of a hack: https://github.com/O...9152d4c92401c44

 

In this case code is *added* to look for a specific screen and override the operation of the code for that screen only.  This was done rather than fixing the actual cause of the issue being reported.  The real fix was only two short line with no convoluted logic!

 

Here is the more comprehensive fix: https://github.com/O...en.py#L151-L152

 

So tell me which version looks more convoluted, harder to read, follow and comprehend?  Which version will be easier to support moving forward?

 

Regards,

Ian.

[littlesat]

In this case code is *added* to look for a specific screen and override the operation of the code for that screen only.  This was done rather than fixing the actual cause of the issue being reported.  The real fix was only two short line with no convoluted logic!

This is indeed not done... and when it is required then do it with a parameter...

[Huevos]

@Abu, here is a visual example of a hack. The bottom of the tree is painted to help motorists avoid it. Was that the correct fix?

 

 tree.jpg   156.71KB   2 downloads