Some Clients not Triggering a Trilateration Attempt

[gregmcdougall]

I often come across systems which, when opening their page, trigger a successful trilateration.

Here are a sample (note the last submitted distance date, versus the successful trilateration date):

https://www.edsm.net/en/system/distances/id/3534166/name/Oorb+Broae+AA-A+h0 https://www.edsm.net/en/system/distances/id/9859732/name/Dryeia+Bleia+HB-O+d6-0 https://www.edsm.net/en/system/distances/id/69383/name/Zuni+AL-P+c5-2346 https://www.edsm.net/en/system/distances/id/82917/name/Phoo+Aeb+OG-N+c20-0

The text file attached list some other system ids which have suffered from the same issue.

I can't tell whether this is a client issue or some other factor at play.

systems.txt

[AnthorNet]

Which client are you using?

Also the trilateration is only done for the main system, and some depending on the results and the time it tooks. We cannot do 80 trilateration in one request obviously!

That said we have a background process doing them shortly after, I might take a look to see if it still works as expected. This background process can handle a system every 5s or minutes, depending on the CPU load at the time of the loop.

[gregmcdougall]

The observed behaviour is from a browser (i.e. I browse to a system and observe it calculates there and then). Take a look at the client adding the latest distance record. EDDiscovery pops up a lot, but not exclusively. I can usually trigger one or two from the pushed list early each morning (from folk entering distances overnight).

[AnthorNet]

Yes, EDD uses the API, and the API only triggers a subset of the trilateration for performance and avoid timeout.

[gregmcdougall]

ok, i think we're almost there now - not a bug? my understanding is this:

1. someone inputs multiple distances via EDD, as here where 33 were inputted with the same timestamp
2. this triggers the API which only triggers a subset of the trilateration for performance and to avoid timeout
3. some of the submitted distances, despite being enough to trigger a successful trilateration, don't because of the above functionality
4. some time later, whether through the addition of another distance, random browsing to the system page, or your catch-up background process, the trilateration takes place (this one, in the list of systems submitted in 1, was calculated 8ish hours later without another distance being added)

before we close this, could you confirm how this background process works through systems? does it / could it work in a way which targets and mitigates the issue caused here?

[AnthorNet]

I ran some tests, and systems are processed by the background process, note that it could take some time to went there ^^ And featured systems aren't pushed to it.