Upstream handlers which require the device's LastPosition are working incorectly in the case of a packet with multiple readings

Supose we have two consecutive packets each containing 2 readings.

1. Packet 1: Reading 1 at - time: 00:00
2. Packet 1: Reading 2 at - time: 00:30
3. Packet 2: Reading 1 at - time: 01:00
4. Packet 2: Reading 2 at - time: 01:30

After the "Packet 1" is processed, we have last position equal to 12
Now, for instance, the distance handler will calculate both distances for 21 and 22 from the point 12, so the distance for 22 will be twice as long.

11 -> D1 -> 12 - D2 -- 21 -> D3 -> 22

D3 will be equal to the distance between the 12 and 22, not between the 21 and 22.

I believe this is a known problem in parsing packets with multiple positions. I have solved it for our use by separating "serial" and "parallel" parsing of incoming positions.

Works mostly like this:

1. packet with multiple positions arrives
2. add each position into "serial processing queue"
3. let the regular parallel parsing do its job
4. when parallel parsing is finished for all positions, I run the serial processing queue.

It gives a little delay, but the data is correctly parsed. It works great for our Ruptelas. I'd share the code (and I will on request), but we are using an outdated version of traccar server, so the rest of the code wouldn't be up to date.

I hope I'll be able to update our code modifications to recent version of traccar and submit the code, but it could take a while since I'm quite busy at the moment. If anyone else would like to fix that issue in recent traccar, I can assist with my solution and code that needs to be adapted to recent version.

Thanks for the idea!

Apropos, you can add an additional upstream remote to your local repository (git remote add). That helps to keep your fork up to date.

Everything should be working correctly, unless you use one of the asynchronous functions. For example, reverse geocoding.