Maybe ping Pieterg and check his reasons for this commit? And what can be done about it?
Scanning issue: Dead/out of footprint transponders
Started by Abu Baniaz, 24 Apr 2018 17:18
49 replies to this topic
Re: Scanning issue: Dead/out of footprint transponders #21
-
- PLi® Core member
- 68,588 posts
+1,738
Excellent
Posted 10 May 2018 - 20:59
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: Scanning issue: Dead/out of footprint transponders #22
-
- PLi® Contributor
- 4,247 posts
+158
Excellent
Posted 10 May 2018 - 22:10
The reason for the commit was HD51 took forever to obtain tuner lock after moving the motor.
But the side effect of the commit is that if a transponder is dead or you are out of the footprint a scan gets stuck on that frequency forever.
So the commit fixes one problem on one receiver and breaks scanning on all receivers.
Re: Scanning issue: Dead/out of footprint transponders #23
-
- PLi® Core member
- 56,271 posts
+691
Excellent
Posted 10 May 2018 - 22:24
Al least it fixes it on one (type) of receiver... better search for a common solution... why does it break something?
At least you found the cullpit...
At least you found the cullpit...
Edited by littlesat, 10 May 2018 - 22:27.
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: Scanning issue: Dead/out of footprint transponders #24
-
- PLi® Contributor
- 4,247 posts
+158
Excellent
Posted 10 May 2018 - 22:57
A[..] does it break something?
Yes. It breaks manual scan on every receiver. If a manual scan comes to a transponder that it cannot lock it just stops on that transponder and the scan doesn't continue. In Abu's test he waited half an hour on one frequency waiting for the scan to proceed to the next frequency, but it does not.
Before the bug was just on HD51 on motor systems. Now it is on every receiver and on motorised and non motorised.
Edited by Huevos, 10 May 2018 - 23:00.
Re: Scanning issue: Dead/out of footprint transponders #25
-
- PLi® Contributor
- 4,247 posts
+158
Excellent
Posted 10 May 2018 - 23:04
Al least it fixes it on one (type) of receiver.
I think you misunderstand. This is a new bug. It affects all receivers, even the one being fixed.
Re: Scanning issue: Dead/out of footprint transponders #26
-
- PLi® Core member
- 56,271 posts
+691
Excellent
Posted 11 May 2018 - 00:40
Mmm I did scan just an empty transponder here on a vu ultimo4k and it does stop after a while....
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: Scanning issue: Dead/out of footprint transponders #27
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 11 May 2018 - 01:18
This bug is on motorised setups. I thought you do not have a motorised dish?
Re: Scanning issue: Dead/out of footprint transponders #28
-
- Senior Member
- 2,616 posts
+30
Good
Posted 11 May 2018 - 08:44
Abu Baniaz, Huevos mentioned the new bug affects both motorised and non-motorised systems.
ET9000, OpenPLi 4.0, 13E, 19E
HD51, OpenPLi 6.2, 75E - 30W
Re: Scanning issue: Dead/out of footprint transponders #29
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 11 May 2018 - 11:16
Oops, thanks. Even more serious then.
Re: Scanning issue: Dead/out of footprint transponders #30
-
- PLi® Core member
- 68,588 posts
+1,738
Excellent
Posted 11 May 2018 - 11:24
To be clear, is this an issue with a valid transponder (i.e. there is a signal on the frequency) that has no channels, or about a transponder that doesn't broadcast (so it waits for a lock indefinitely)?
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: Scanning issue: Dead/out of footprint transponders #31
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 11 May 2018 - 11:39
If out of footprint, I'd say it's invalid for that user.
Re: Scanning issue: Dead/out of footprint transponders #32
-
- PLi® Core member
- 68,588 posts
+1,738
Excellent
Posted 11 May 2018 - 11:58
So the problem is waiting for lock?
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: Scanning issue: Dead/out of footprint transponders #33
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 11 May 2018 - 12:04
I suppose yes. But it depends on what you define as lock.
Re: Scanning issue: Dead/out of footprint transponders #34
-
- PLi® Core member
- 68,588 posts
+1,738
Excellent
Posted 11 May 2018 - 12:27
Are there multiple definitions? 
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: Scanning issue: Dead/out of footprint transponders #35
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 11 May 2018 - 12:37
Lock on a signal.
Lock on the defined TP.
As the dish moves it gets several signal locks. Those locks are ignored because we need to lock on the transponder before scanning commences. This wait is necessary because we do not want to start scanning prematurely.
However, if we do not get the TP lock, we now stall. This did not happen before.
Lock on the defined TP.
As the dish moves it gets several signal locks. Those locks are ignored because we need to lock on the transponder before scanning commences. This wait is necessary because we do not want to start scanning prematurely.
However, if we do not get the TP lock, we now stall. This did not happen before.
Re: Scanning issue: Dead/out of footprint transponders #36
-
- PLi® Contributor
- 4,247 posts
+158
Excellent
Posted 11 May 2018 - 17:43
Sorry, just to be clear, on a motorised setup if there is insufficient signal to get tuner lock, the scan stalls on that transponder and the wait is indefinite.
This maybe be a valid transponder and the user is out of the footprint. Or the the transponder is dead. Either way enigma should be able to cope with such a situation.
Re: Scanning issue: Dead/out of footprint transponders #37
-
- PLi® Core member
- 68,588 posts
+1,738
Excellent
Posted 11 May 2018 - 17:52
Ok, clear. So it is "no lock" that triggers it, not "no services" like Littlesat tested.
And indeed, the "no lock" should timeout, and then it should move on.
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: Scanning issue: Dead/out of footprint transponders #38
-
- PLi® Core member
- 32,766 posts
+245
Excellent
Posted 14 May 2018 - 09:23
Abu Baniaz, Huevos mentioned the new bug affects both motorised and non-motorised systems.
If that is the case, this cannot be related to commit https://github.com/O...64cb9a3340b0508
because that commit only affects the state machine which is used for a motorized system.
Anyway, there is a mistake in that commit, the rotor timeout jump is one off, now that a new state has been introduced.
That clearly causes the issue described in the first post of this thread.
I'll fix it.
All other tune failures / scanning issues (especially those on non-motorized systems) are unrelated though.
Re: Scanning issue: Dead/out of footprint transponders #39
-
- PLi® Core member
- 32,766 posts
+245
Excellent
Posted 14 May 2018 - 09:44
The reason for the commit was HD51 took forever to obtain tuner lock after moving the motor.
More precisely: the commit adds support for frontends which report an FE_TIMEDOUT event when a tune attempt times out.
This is a valid event, many frontend drivers do generate it, so e2 should properly handle it in my opinion.
I'm sorry there was a mistake in the statemachine logic, causing issues in combination with non-working transponders.
Thanks for bringing it to my attention.
I believe it should be fixed now.
Re: Scanning issue: Dead/out of footprint transponders #40
-
- PLi® Contributor
- 2,439 posts
+62
Good
Posted 14 May 2018 - 13:15
I applied this to OpenVix and built an image. It works, thanks.
It waits 5/6 minutes before going to second TP. Can this be reduced to 2 minutes?
It waits 5/6 minutes before going to second TP. Can this be reduced to 2 minutes?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
