Hi,
Are you using latest Traccar (server) release?
Positions are stored in the database if there was some connection problem or if server hasn't replied. Are you sure those messages are duplicates? And if yes, do you see reply from the server in the log?
Hey Anton,
As I mentioned in the initial message, I'm using the latest development source for the server.
I believe I am seeing the 'OK' heading back to the client in the logs, yes.
I noticed that after shutting down the android app, that the traffic on port 5055 stopped, and, again, once the client was started up, that it resumed the flurry of activity on port 5055.
having allowed the client time to 'catch up', it seems that the activity is pretty much what I expect to see.
but, this seems to suggest to me that the client itself may be saving the location updates, and keeps sending them on startup until they are acknowledged.
is that correct?
does the client hang on to unacknowledged location reports and re-send them at some later opportunity?
If that's what's happening, perhaps it would be a good idea to allow the user to configure the client as to whether unacknowledged location updates are discarded or stored.
it would help get the current location visible on the server more quickly, based on what I'm seeing, and really, I'm not too interested in where they 'were', just where they 'are'.
I can well imagine others will want to know where it was. hence, the configuration option would be a benefit.
regards,
peter
Yes, it saves GPS locations if network is not available and sends it later.
I guess it makes sense to provide an option for the user to disable this functionality. Another solution is to send latest data first as it's probably more important as you pointed out.
Hey Anton,
using the latest android client with the latest development version of the server code, it appears that when the client is turned on, it is sending afresh, copies of old position reports.
On the server side, watching the tracer-server log file, I see lots of messages with timestamps of yesterday (for example).
Watching tcpdump on port 5055, proves to me that the data is coming from the mobile handset.
Also, while the data is streaming, rebooting the phone kills the flow of data.
Is the client storing position reports it thinks are not delivered for redelivery at some later time, and this mechanism is seemingly not clearing the old data?
please advise.
best regards,
peter