186 replies to this topic

[arn354]

https://github.com/o...83f4492c36e3ff4

This one adds a configuration option to use old behaviour (fast) and new behaviour (reliable).

 

Fast simply causes tuning issues in some conditions - depending on used unicable hardware (and partly drivers of stb) - even in the current version of openPli Unicable not every regular unicable hardware is properly working on every stb (that's why people need to use satelitequipmentcontrol to add some delay for example).

Reliable the tuning sequence will take a "little" longer and simply tune "reliable" - despite of used unicable hardware (or stb drivers) and sateliteequipmentcontrol is obsolete using "reliable".

Edited by arn354, 12 April 2016 - 15:50.

[littlesat]

Thanks for your reply....

 

So I understand that really timing issues are involved here.... And that is why you added as a work-a-round a 'normal/fast' and 'reliable/slower' mode... and you also mentioned it could be driver and JESS hardware related...

 

I'm afraid we only could except a patch when it is really clear... And sorry we really need some help here...

 

I also understand now that you read here and tried to improve what we mentioned here... As I can see the patch you showed was later implemented. very appreciated!!!

 

I can consider to setup a jess-testing branch and start all over again. But I do not want to bypass Erik here... I know there can be a lot of stuff cleaned/improved here but testing is required...

 

But just to give you comments on you latest reliable commit...

 

You use an important integer SatCR_switch_reliable... which is in fact a bool.... I would declare declare it as a bool.... And rename setLNBSatCRTuningAlgo to setLNB_switch_reliabe... (with Value True, False)... or are you planning more modes in future? or something like that...

Edited by littlesat, 12 April 2016 - 16:07.

[arn354]

The JESS branch is still there on openpli enigma2 - https://github.com/O...igma2/tree/jess

My suggestion would be

* to add the last additional changes

* to improve the code where possible and necessary

In addition i would like to add that now (as it is) in openATV or openMips unicable works perfect tested with unproblematic and problematic unicable hardware (unicable I or unicable II).

Edited by arn354, 12 April 2016 - 16:04.

[littlesat]

We can do it differently... set-up a working branch (jess-test) and then try to clean it up as far as possible... But still someone of us need to help and we cannot test.... (we can only test if it does not has any effect on the current situation).

So at this moment I personally can only help by looking analytically to the code...

Edited by littlesat, 12 April 2016 - 16:09.

[arn354]

"Fast" should not really change the current situation (referring to the one comment of a Pli-member that tuning is slower with new implementation).

People with problematic unicable hardware or problematic stb drivers need to use sateliteequipmentcontrol as they do it now anyway if needed.

People with non-problematic unicable-hardware or non-problematic stb drivers should not notice a difference in behaviour to existing unicable implementation of openPli.

 

All i can say that using openPli and various unicable equipment and various stb's it even now does not work reliable in openPli - so it would be an improvement even for openPLi . Yes - it works now for some (maybe a lot), but not all conditions.

 

I would declare declare it as a bool.... And rename setLNBSatCRTuningAlgo to setLNB_switch_reliabe... (with Value True, False)... or are you planning more modes in future? or something like that...

 

good point

Edited by arn354, 12 April 2016 - 16:22.

[athoik]

I also looked at the code, and cleanup several parts in python in my branch.

But when it comes to questions in C++ code, eg why we introduced the "FBC like" tuner of linked tuners there was no usefull responce.

The current code might be working in OE-A, but requires lot of changes and cleanup.

One way or another, it requires reading specification, access to hardware and time.

I can clean up code in openpli jess branch, but some parts of the code are hurting my eyes.

[athoik]

Here is a nice way to reduce python code:
 

+			tmp = ConfigSubList()
+			for i in (1284, 1400, 1516, 1632, 1748, 1864, 1980, 2096):
+				tmp.append(ConfigInteger(default=i, limits = (950, 2150)))
+			section.satcrvcouserEN50494 = tmp
+
+			for i in (1284, 1400, 1516, 1632, 1748, 1864, 1980, 2096) * 3:
+				tmp.append(ConfigInteger(default=i, limits = (950, 2150)))
+			section.satcrvcouserEN50607 = tmp

Also see this one: http://forums.openpl...e-4#entry535447

Edit1. And this one: http://forums.openpl...e-4#entry535467

I don't get it

Edited by athoik, 12 April 2016 - 16:37.

[Huevos]

@Athoik, the JESS code came one year beforethe fbc code. If PLi had merged it at that time we wouldn't be having this discussion now about similarities. It is a case of dual evolution. Both lines of code have independently evolved to suit current requirements with neither borrowing from the other.

[littlesat]

Thanks adhoik you exactly desribe our concerns...the big pain here is that we need to keep the code clean and good... This helps to keep it readable and maintainable. Possibly when this was done something like traditional and reliable mode wasn' t even required at all... But anyway because we try to avoid quick and dirty we miss features...

Another nice thing to reduce python code.. (in speudo)

SetLNBSwitch_mode(config == "reliable")

Saves three lines with and or structure... Or with integer as it is now..jj

SetLNBSwitch_mode(config == "reliable" and 1 or 0)

And huevos, indeed we are somehow late... But from the other side the other team has now issues with the fbc tuner optimalization... So when we somehow get it merge both can profit... But before I can really help here I need Jess equipment... i can only help by just looking at the code and concult isome optimizing ideas...

And indeed I forgot about our fbc implementation....

Edited by littlesat, 12 April 2016 - 18:08.

[arn354]

The FBC like mentioned code is for internal connectable tuners which exist in several stb's (before FBC tuners appeared).

The unicable commands should be send by tuner which has the physical cable connected if i recall correctly, not by the tuner which is internally connected.

Edited by arn354, 12 April 2016 - 18:31.

[Huevos]

Littlesat, OpenViX and OpenMIPS have the best of both worlds... FBC code from PLi and all the JESS improvements, including the fast option. The Solo4K/JESS work really sweet like this.

[littlesat]

But I'm afraid we have clean FBC and scary JESS..... But it can be a good start to get this re(adapted) to openpli....

 

But when we make a new branch it should be work together to improve it.... And with improve I mean clean the code, make it more readable for your eyes, without loosing but improving functionality...

 

But still we need JESS by ourselves for testing...

Edited by littlesat, 12 April 2016 - 19:36.

[littlesat]

As far can see VIX and openMIps does not have the FBC improvements which OpenPLi has....  I see only the somehow basic patch from VU committed.... So sorry as far I can see not the best of two worlds....

Edited by littlesat, 12 April 2016 - 19:43.

[Huevos]

Littlesat, all the FBC code from OpenPLi is in OpenViX  and OpenMIPS.

 

I merged all the JESS code into OpenViX. All the individual commits are here: https://github.com/H...ts/JESS-commits

 

Then I made it into one big commit here: https://github.com/H...03654d76bdcb5c1

 

And then I picked that commit into OpenViX here: https://github.com/O...9d8fc15352577e0

 

Then I just cherry-picked my patch into OpenPLi here (+ the xml file): https://github.com/O...9d8fc15352577e0

 

If OpenViX were not using the same FBC code there would have been terrible merge conflicts..

Edited by Huevos, 12 April 2016 - 20:10.

[littlesat]

I understand... So I hope it still can be cherry picked...

[littlesat]

But still the q of the jess existing jess code is terrible... I do agree with adhoik, it hurts your eyes. The orriginal vu patch is clean as far I can see. To get this accepted it really needs some kind of rewriting, So as far I can see the.current jess code needs a lot of changes to be accepted by the openpli team...

So we are a bit more than a month further and still no jess openpli....

Edited by littlesat, 13 April 2016 - 07:09.

[Huevos]

All the code is from the same author (dvb-adenin) so I can't understand the opinion that one commit is far better quality than the rest.

[littlesat]

It is difficult to give critics to someone else's code as I'm 100% a lot of you can also have comments on my commits...

 

For JESS in openpli it needs to be improved.... All help is appreciated...

Edited by littlesat, 13 April 2016 - 08:12.

[malakudi]

But still the q of the jess existing jess code is terrible... I do agree with adhoik, it hurts your eyes. The orriginal vu patch is clean as far I can see. To get this accepted it really needs some kind of rewriting, So as far I can see the.current jess code needs a lot of changes to be accepted by the openpli team...

So we are a bit more than a month further and still no jess openpli....

 

Sorry littlesat but this is far from truth. I would agree if the complete code of enigma2 was perfect. But it is not. There are many sections that the code is far worse than at least the original JESS patch. And if you are reviewing code, you don't reply as "quality of the code is terrible". Point to certain sections of the source that need to be changed in order to get committed.

We have a big problem in development process. We have become so much bureaucrats that we had to talk for days (or maybe weeks?) to just change a default debug log level from 4 to 3. Sorry but this is getting nowhere. I am not supporting the oe-alliance model which applies patches for everything, but we have gone way far to the other side by not applying anything.

[littlesat]

At least the openPLi team arrange the level 3/4 and more possibility in a structured way why firstly eDebugs were only suggested to commented out.... 

 

At least I could re-offer a new test-jess branch so who can develop (build images) can build and test so we have at least a platform for testing and improvements. I suggest that is a good step to begin with... 

 

I agree using 'terrible' here in this content is likely not the best expression from my side... and this is something I do not really mean that way.... Especially I'm also a coder so I'm aware it took a lot of time to implement...

 

Please note it has nothing to do with 'bureaucrats policy'...