49 replies to this topic

[Abu Baniaz]

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

•  pli hd51 scan 15w.jpg   43.54KB   4 downloads
•  Mutant scan pli.txt   79.51KB   12 downloads

[el bandido]

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

[el bandido]

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.

[Abu Baniaz]

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.

[Rob van der Does]

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.

[el bandido]

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.

[Huevos]

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.

[Erik Slagter]

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

[Robinson]

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

[Abu Baniaz]

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.

[Huevos]

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.

[Abu Baniaz]

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

[eDVBFrontend] rotor timout

[Huevos]

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

[Abu Baniaz]

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

[Huevos]

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

[Abu Baniaz]

Give up completely or move onto next TP?

[Abu Baniaz]

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.

[janejak]

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

[Huevos]

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

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

[Huevos]

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.