Major Traccar Client update
I understand that enabling offline buffering would technically solve this scenario, but it is not always the ideal solution.
The main reason is that, if a user has been moving while offline for an extended period, reconnecting to the internet causes the client to upload every buffered location update. This can result in a large burst of requests being sent to the server.
For many deployments, this is unnecessary because the server is only interested in the user's current location, not the entire path they took while offline. Uploading dozens or even hundreds of historical positions consumes bandwidth, increases server load, and provides little value in those cases.
An alternative approach could be to add an option that, upon reconnecting, only retries sending the last known location instead of the entire offline buffer. This would keep the server synchronized with the device's current position without flooding it with historical updates.
Including the current coordinates in the heartbeat request would also solve this problem. As soon as the device reconnects and sends its first heartbeat, the server would immediately receive the user's latest location, even if all intermediate location updates were missed while the device was offline.
I would recommend splitting it into a separate feature request on GitHub.
Why would the coordinates be outdated in a heartbeat. The user is stationary anyways so the coordinates shouldn't be different, right?
Ok fair enough. Can be splitted into a new github feature request. Will try to do it later on. Thanks
This will only happen if you have buffering disabled, which I won't recommend doing.
The main issue with including coordinates is that they might be outdated, but the time will be new, which results in potentially false information to the end user.