Jump to content


Photo

nimmanager.somethingConnected() broken logic


  • Please log in to reply
74 replies to this topic

#1 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 16:37

This is the broken commit:

https://github.com/O...519d0ab55099cb4

 

Configuration:

Vu+ Solo2:

Tuner A. is configured, e.g. Simple, Single, 19.2 east.

Tuner B is "disabled".

 

Problem:

nimmanager.somethingConnected() returns False.

This means "manual scan" and "auto scan" are now missing from the Solo2 menu.

 

Reason:

https://github.com/O...Manager.py#L977

and self.nim_slots[id].internally_connectable != id - 1:

What is that doing there? What does "internally_connectable" have to do with whether or not a tuner is configured?

Also the Solo2 is "internally_connectable" but the cable has to go to tuner B and tuner A is the slave.If the cable goes to tuner A, tuner B cannot connect to it.

This means "and self.nim_slots[id].internally_connectable != id - 1:" will always return False.

 

So what was the logic behind the commit, and how can we solve it so it works properly.

 

That also means logic is knackered here:

https://github.com/O...Manager.py#L838

entry["internally_connectable"] = entry["frontend_device"] - 1

Correct logic for Solo2 Tuner A should be:

entry["internally_connectable"] = 1

Edited by Huevos, 26 June 2018 - 16:39.


Re: nimmanager.somethingConnected() broken logic #2 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 26 June 2018 - 16:41

The commit is not really broken... what vu is doing here is Some maddness...
You should not do that connect A and then not B... connect B and not A is Ok what you should do with this vu and at the end it does not care when you have one cable an connect it to’B and then this is a non issue...

Actually somehow vu swapped a and b.... and therefor I think we should keep the code simple and not try to work a round it.....

As far I remember the A to B switch is covered somewhere else... (as DMM8k had a ‘cross’ switch)

Edited by littlesat, 26 June 2018 - 16:47.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #3 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 16:54

Bug exists for all machines that use 7356 CPU. We at least need a workaround so "manual scan" and "auto scan" are available in the menu.



Re: nimmanager.somethingConnected() broken logic #4 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 26 June 2018 - 16:55

When you connect B only there should be no issue... connect A only is wrong! So no work a round needed....
so when you only have one connection then connect to B instead of A is what should be done!

Edited by littlesat, 26 June 2018 - 16:56.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #5 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 16:57

But what is the purpose of checking "internally_connectable"? There is a cable attached and set up on tuner A so why does this need to fail?



Re: nimmanager.somethingConnected() broken logic #6 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 26 June 2018 - 17:01

The issue is in fact that tuner A should be B and B should be A.... when you have one cable it is mandatory to connect the cable to B and you limit yourself when you disable A...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #7 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 17:02

When you connect B only there should be no issue... connect A only is wrong! So no work a round needed....
so when you only have one connection then connect to B instead of A is what should be done!

How is a typical OpenPLi user supposed to know that?



Re: nimmanager.somethingConnected() broken logic #8 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 17:07

The issue is in fact that tuner A should be B and B should be A.... when you have one cable it is mandatory to connect the cable to B and you limit yourself when you disable A...

Why is it "mandatory" to connect the cable to tuner B? Before this commit it used to work fine on either tuner.

https://github.com/O...ea0b02ee28d52b3


Edited by Huevos, 26 June 2018 - 17:07.


Re: nimmanager.somethingConnected() broken logic #9 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 17:09

Also I don't understand why "internally_connectable" is being tested at all. Please explain why it is needed.


Edited by Huevos, 26 June 2018 - 17:10.


Re: nimmanager.somethingConnected() broken logic #10 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 26 June 2018 - 17:19

Without that commit something else does go wrong... it is needed to ‘combine’ dual tuners... and of course e2 knows there is a switch between tuners...and vu one cable connect to always to B and also enable tuner A... don’t limit yourself.. and also but the cable with most sats to B... never disable a tuner on a dual tuner! Always connect one and for this vu box it is Tuner labled as B instead of A

Edited by littlesat, 26 June 2018 - 17:23.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #11 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 26 June 2018 - 18:39

Littlesat, you're trying to "solve" a "problem" (which is debatable) for FBC tuners. Why limit the functionality for normal tuners in the same run? It's not logical. There is nothing that says it's illegal to develop a receiver that can only loop B to A instead of A to B. As long as they note it correctly in the API, it's fine. I don't see why would need to frustrate that (including the users).


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: nimmanager.somethingConnected() broken logic #12 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 18:39

Without that commit something else does go wrong

Thanks for the explanation.

 

Can you tell me what "goes wrong"?

 

I have searched enigma and can't find anything that requires "and self.nim_slots[id].internally_connectable != id - 1".

 

  • openpli-enigma2-github/data/menu.xml
  • openpli-enigma2-github/data/startwizard.xml
  • openpli-enigma2-github/lib/python/Components/NimManager.py
  • openpli-enigma2-github/lib/python/Plugins/SystemPlugins/FastScan/plugin.py
  • openpli-enigma2-github/lib/python/Plugins/SystemPlugins/PositionerSetup/plugin.py
  • openpli-enigma2-github/lib/python/Plugins/SystemPlugins/Satfinder/plugin.py
  • openpli-enigma2-github/lib/python/Screens/ScanSetup.py
  • openpli-enigma2-github/lib/python/Screens/TimerEntry.py


Re: nimmanager.somethingConnected() broken logic #13 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 26 June 2018 - 19:22

@Erik,

 

One of the problems is here:

.
			if "frontend_device" in entry: # check if internally connectable
				if os.path.exists("/proc/stb/frontend/%d/rf_switch" % entry["frontend_device"]) and (not id or entries[id]["name"] == entries[id - 1]["name"]):
					entry["internally_connectable"] = entry["frontend_device"] - 1

So to check for internal connectivity the check is just that the proc exists. But there is nothing in the code to show how it is internally connectable. So it is just assumed as "current slot - 1".

 

Then later this same logic is applied to "slot.friendly_full_description_compressed". Everywhere in nimmanager it is assumed the connected tuner will always be the first tuner of a dual tuner.


Edited by Huevos, 26 June 2018 - 19:26.


Re: nimmanager.somethingConnected() broken logic #14 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 26 June 2018 - 19:37

Shouldn't those scan menu conditions be just checking whether a tuner is configured or not?

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

Re: nimmanager.somethingConnected() broken logic #15 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 26 June 2018 - 22:53

Actually it does... except for leave fbc tuners... and when the connector is looped.. the other one should be connected... current slot - 1 is usually right except for the madness b is looped to a, which is not logical at all... again connect the coax to b when you have one coax sonwe don’t need to add if vu than do something else stuff in the code... and again at the and the one coax is then also looped to a... as a cannot be looped to b...

Edited by littlesat, 26 June 2018 - 22:59.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #16 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 June 2018 - 00:15

As mentioned above it is not just Vu who have this issue. All receivers with the same SoC have this issue.

People with this issue are not setting the other tuner as "loop through", it is being set as "nothing connected".

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

Re: nimmanager.somethingConnected() broken logic #17 littlesat

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 27 June 2018 - 06:49

Why should you set it as not connected?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: nimmanager.somethingConnected() broken logic #18 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 27 June 2018 - 08:28

To needlessly limit yourself/your box.

Re: nimmanager.somethingConnected() broken logic #19 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 27 June 2018 - 09:53

Why should you set it as not connected?

Because it is a valid setup.

Also you still haven't answered the question why this rogue code is needed. I can't find any reason for it. Is it part of an elaborate hidden hack? We should be testing for a connection. Not a loop through.

The code should work for any valid setup.

Re: nimmanager.somethingConnected() broken logic #20 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 27 June 2018 - 09:58

To needlessly limit yourself/your box.

Isn't that what peple that use loop through are already doing? But anyway that is a different discussion.

What i am trying to find out is what this hack is there for


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users