Jump to content


Photo

nimmanager.somethingConnected() broken logic


  • Please log in to reply
74 replies to this topic

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

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 28 June 2018 - 23:50

It seems we indeed can better add the non loopthrough çonfigured check.... It might happen the config is on loopthrough (in the background) while the other tuner is not connected,,,

 

https://github.com/O...d0ed80438863cd1

Yes, I agree. Just being in loopthrough doesn't prove anything is connected.

 

Anyway thanks for these commits.



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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 29 June 2018 - 06:54

Nothing is blocked anymore... the intent/purpose is solved differently... loop through is not taken into account for connected, as where it is looped to should be connected..
But this time it was hard to understand as the vu issue was a symptom and not the problem... so first I had to extract the real problem (before I blindly remove/adapt this check). This wa also the reason why I defend the symptom as the code has an intent! And it was easy to defend...

When the tuner we loop through isn’t connected that is covered now... except now for the individual connected check. We need now to check if this check is really needed... then we could also indeed consider to (move) an when we have a loop through configured tuner is the tuner we loop through connected...

Edited by littlesat, 29 June 2018 - 07:03.

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


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

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 6 July 2018 - 10:10

@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.

Thank you for this information. So that means that the only way to make this work on a Solo4k (or similar receiver) is to add a "if machine == vusolo4k then ..." construct?

 

In that case these users should really use extern loopthrough, issue solved ;)


Edited by Erik Slagter, 6 July 2018 - 10:15.

* 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 #44 Huevos

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 6 July 2018 - 12:28

 

@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.

Thank you for this information. So that means that the only way to make this work on a Solo4k (or similar receiver) is to add a "if machine == vusolo4k then ..." construct?

 

In that case these users should really use extern loopthrough, issue solved ;)

 

Littlesat has cured one problem in somethingConnected() but the other remains. External loopthrough doesn't solve the problem. The tuner will still be listed with incorrect internal loopthrough. Affect all receiver that use the 7356 SoC.



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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 12:49


Affect all receiver that use the 7356 SoC.

 

Actually this is not true... It only indicates all receivers using these SOCs have on the outside of the box A printed at B and B at A and in addition in the drivers they are also swapped...  (and probably they did continue this due to VU started it...???)

 

And indeed I solved the 'real' issue in an smart way....but which other issue do we still have?

And now I repeat again.... For all these boxes it seems when you have one cable you HAVE to connect it to B instead of A... as when you connect to A you cannot use tuner B at all... When you connect to B, A can be used... SHORTLY... when you only connect to A is WRONG... Even when you disable tuner B (why should you disable a tuner, because you can?)
 


Edited by littlesat, 6 July 2018 - 12:52.

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


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

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 6 July 2018 - 12:52

Here:

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

For the 7356 SoC it should be:

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

But that screws the logic behind the compressed tuner names.



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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 12:53

Nope.... we refused this ugly patch years years years ago....! I still can remember the long discussions about it...

 

Actually when OE-A did refuse it also years years years ago we did not get this discussion now....

There is no way designed at this moment that can tell E2 that we have the situation where B can connect to A and A not to B... 

 

This can only be done with a if VU then -or- probably with an if SOC 7356 then.... And it 'screws' more than the combined tuner stuff!!!

 

And when you connect to B first this should be no issue at all...!!!!!


Edited by littlesat, 6 July 2018 - 12:55.

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


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

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 6 July 2018 - 13:05

Littlesat, I am happy with your solution, I was only trying to better explain the problem to Erik. It is not only the sockets swapped because Nim 0 is tuner A and Nim 1 is tuner B. And this is the case on all hardware that uses 7356.



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

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 6 July 2018 - 13:14

There is no way designed at this moment that can tell E2 that we have the situation where B can connect to A and A not to B...

 

You keep confusing things in your posts. Rob has already mentioned this to you. Just to clarify

 

A can connect to B

B cannot connect to A

 

Signal wire must be in B



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

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 6 July 2018 - 14:33

 

There is no way designed at this moment that can tell E2 that we have the situation where B can connect to A and A not to B...

 

You keep confusing things in your posts. Rob has already mentioned this to you. Just to clarify

 

A can connect to B

B cannot connect to A

 

Signal wire must be in B

 

Littlesat is correct. There is no way for the driver to pass this data to enigma. All we have is the presence of a /proc. But the /proc doesn't tell us which tuner the current tuner can be connected to. So it is assumed to be the the prior one, not the next.


Edited by Huevos, 6 July 2018 - 14:35.


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

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 6 July 2018 - 14:57

My point is his wording is contradictory. It is wrong in places.

A can connect to B.

Edited by Abu Baniaz, 6 July 2018 - 14:58.


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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 14:58

And the actual mistake is they printed on the box A where it should be B and B where is should be A.... And fixed it within the drivers to work-a-round the printing..


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


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

  • PLi® Contributor
  • 4,229 posts

+158
Excellent

Posted 6 July 2018 - 16:27

And the actual mistake is they printed on the box A where it should be B and B where is should be A.... And fixed it within the drivers to work-a-round the printing..

Now I am not sure if you are serious. So every manufacturer that uses this SoC made the same printing error, right?

 

Attached File  20180706_170624_resized.jpg   130.27KB   0 downloads



Re: nimmanager.somethingConnected() broken logic #54 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 6 July 2018 - 17:11

I think his point was that if on the packaging it was printed that "B loops through to A", from which follows that if you have only one cable you should connect it to B, then no workarounds were needed anywhere.
 
Now the text on the packaging doesn't correspond with the way the hardware was designed ( which confuses a lot of people who assume A should be connected and not B ) and a software workaround was needed to fix the hardware design flaw.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 17:14

Yes I'm serious... When in the drivers -and- the print on the box they swapped it we had in E2 no issue... That more manufacturers seems to have the issue on the same soc is no argument.... That is more obvious...


Edited by littlesat, 6 July 2018 - 17:15.

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


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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 17:16


I think his point was that if on the packaging it was printed that "B loops through to A", from which follows that if you have only one cable you should connect it to B, then no workarounds were needed anywhere.
 
Now the text on the packaging doesn't correspond with the way the hardware was designed ( which confuses a lot of people who assume A should be connected and not B ) and a software workaround was needed to fix the hardware design flaw.

Rofffll....


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


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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 6 July 2018 - 17:17

And so nice this topic and discussions are coming back after years, years and years several times.... by a simple tuner swap issue that was work-a-round....


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


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

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 7 July 2018 - 05:00

In that case these users should really use extern loopthrough, issue solved ;)

If only that were true; Solo2 has no LNB-out ports......

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

  • PLi® Core member
  • 56,123 posts

+685
Excellent

Posted 7 July 2018 - 07:19

Then you need a splitter... or simply connect to B...

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


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

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 7 July 2018 - 08:22

Littlesat has cured one problem in somethingConnected() but the other remains. External loopthrough doesn't solve the problem. The tuner will still be listed with incorrect internal loopthrough. Affect all receiver that use the 7356 SoC.

It may not solve "this" problem, bit it does allow the user to loopthrough.


* 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.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users