Jump to content


Photo

Scanning issue: Dead/out of footprint transponders


  • Please log in to reply
49 replies to this topic

#1 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 24 April 2018 - 17:18

There seems to be a problem with scanning on a motor. If the transponder is dead, out of footprint area or dish is slightly out, the scanning does not progress to the next TP. It stalls trying to scan the first listed Transponder forever. I waited 20 minutes in one test.

I tested this with:
Mutant HD51 on 6.2 RC 2018/04/24
1.1 Triax dish
TM 0.1 Gold single LNB
Tuner is set as simple, positioner(selecting satellites)
No other options were changed

The same issue is present on latest Developer OpenViX image using a Solo 4K using the FBC tuner.

We suspect that this commit partly responsible
https://github.com/O...c96ca95eadf3ac9

Is it possible we can have a look at the issue please?
Thanks in advance

Attached Files



Re: Scanning issue: Dead/out of footprint transponders #2 el bandido

  • Senior Member
  • 360 posts

+13
Neutral

Posted 25 April 2018 - 18:18

Interesting.
Do you think all models of receivers are affected? I will try to see if I have the same issue on my receivers.



Re: Scanning issue: Dead/out of footprint transponders #3 el bandido

  • Senior Member
  • 360 posts

+13
Neutral

Posted 26 April 2018 - 07:44

I see the same issue with a Zero 4K using OpenPLi RC, updated on 4-24-2018.


Edited by el bandido, 26 April 2018 - 07:44.


Re: Scanning issue: Dead/out of footprint transponders #4 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 26 April 2018 - 08:16

Thanks for confirming.

Report from the other forum, even scanning 19.2 failed because the first listed transponder is no longer active.

Updating xml file circumvents the bug.

Re: Scanning issue: Dead/out of footprint transponders #5 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 26 April 2018 - 08:23

Updating xml file circumvents the bug.

But only for a specific situation. There will always be transponders that can't be received from a specific location/by a specific configuration.



Re: Scanning issue: Dead/out of footprint transponders #6 el bandido

  • Senior Member
  • 360 posts

+13
Neutral

Posted 26 April 2018 - 17:01

Transponders go dark in North America all the time. So we would be constantly updating the satellites.xml file to fix this. Most scans that are done here would be blindscans, and that part of the image is not bothered by this problem. It is only seen in the manual or automatic scan.



Re: Scanning issue: Dead/out of footprint transponders #7 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 27 April 2018 - 08:03

This needs urgent attention.

 

Updating the xml file is not a fix. The xml file is always going to contain some transponders each person cannot receive at their location.

 

Transponders go dead all the time. And also lots of people are out of the footprint. But... neither of these should cause a box to get stuck trying to scan one transponder for 20 minutes. This never happened before the commit mentioned above that was designed to fix dodgy drivers on some boxes (HD51). Now the situation is much worse and all receivers are affected.


Edited by Huevos, 27 April 2018 - 08:06.


Re: Scanning issue: Dead/out of footprint transponders #8 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 27 April 2018 - 10:22

I agree. Waiting for lock should never take more than ~20 seconds. Maybe a bit more with a rotor.


* 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: Scanning issue: Dead/out of footprint transponders #9 Robinson

  • Senior Member
  • 2,614 posts

+30
Good

Posted 27 April 2018 - 10:26

Maybe that should be configurable. With a rotor you sometimes need 90 seconds to get from extreme left to extreme right.


ET9000, OpenPLi 4.0, 13E, 19E

HD51, OpenPLi 6.2, 75E - 30W


Re: Scanning issue: Dead/out of footprint transponders #10 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 April 2018 - 11:57

On motor setups, the first lock check should take longer, subsequent ones should be same as fixed dish and non-sat.

However, the bug is that it times out waiting for a lock but still does not go to the next TP.

By the way, I cancelled after 20 mins. It would have waited forever if I hadn't cancelled.

Re: Scanning issue: Dead/out of footprint transponders #11 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 27 April 2018 - 12:42

Lock timeout is based on symbol rate. That is already written into enigma.

Realistic timeout a motor is 1 degree per second. Maximum possible arc is about 140 degrees. So total 140 seconds. My positioner takes about 2 minutes to go from 61W to 57E.

Re: Scanning issue: Dead/out of footprint transponders #12 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 April 2018 - 13:17

Can we concentrate on the scanning instead of timeout value please? The timeout value can be tweaked later.

[eDVBFrontend] rotor timout


Re: Scanning issue: Dead/out of footprint transponders #13 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 27 April 2018 - 16:26

How? Before you can scan you need tuner lock. Box is waiting for lock.

Re: Scanning issue: Dead/out of footprint transponders #14 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 April 2018 - 16:40

It will never get a lock on the transponder if transponder is dead or you are out of the reception footprint.

Re: Scanning issue: Dead/out of footprint transponders #15 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 27 April 2018 - 19:48

Which is why it needs to know how long to wait before giving up.



Re: Scanning issue: Dead/out of footprint transponders #16 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 April 2018 - 19:57

Give up completely or move onto next TP?

Re: Scanning issue: Dead/out of footprint transponders #17 Abu Baniaz

  • PLi® Contributor
  • 2,414 posts

+61
Good

Posted 27 April 2018 - 20:17

We had this discussion before, there are possible scenarios
1. lock onto a signal
2. lock onto a signal on the desired satellite
3. lock onto a signal on the desired satellite and the desired transponder

Considerations
A. we don't want to start scanning prematurely and miss off some transponders
B. we can't know for definite we are on the correct satellite
C. we need to give up on the first TP after a certain amount of waiting/trying and then move on to subsequent TPs
D. Once we have done C, the assumption should be we are on the desired satellite and not wait for the same duration on these subsequent TPs. This wait duration should be the same as the duration during fixed satellite scans.


The bug at the moment is we are waiting forever for a lock on the first TP. It never happens and we sit there forever.

Edited by Abu Baniaz, 27 April 2018 - 20:19.


Re: Scanning issue: Dead/out of footprint transponders #18 janejak

  • Senior Member
  • 284 posts

+11
Neutral

Posted 28 April 2018 - 02:30

I have tested on my dm900 with PeterPan 2017-Stealth image it take 6:50 min to scan all frekvensy on 13E i get 1983 channel`s found

checked on 28.2E a satelite i dont get any scannel on it take 6:10 min

edit it find 11 channel never happen before



Re: Scanning issue: Dead/out of footprint transponders #19 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 28 April 2018 - 22:00

I have tested on my dm900 with PeterPan 2017-Stealth image

What does that have to do with this bug in OpenPLi.



Re: Scanning issue: Dead/out of footprint transponders #20 Huevos

  • PLi® Contributor
  • 4,231 posts

+158
Excellent

Posted 10 May 2018 - 20:53

So the bug introduced into PLi by this commit https://github.com/O...c96ca95eadf3ac9 and that affects tuning on all receivers can't be fixed?

 

Maybe it should be reverted then.


Edited by Huevos, 10 May 2018 - 20:53.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users