Track points duplicating Patrol Stop messages

We’ve had a number of instances when a patrol is stopped that a track point has been generated at the same date and time and with the same location as the stop message. These track point messages fail to process in Smart Desktop if they are being processed after the Stop Patrol message has already been processed. Although they are redundant data and could be ignored/deleted they sit in the data queue as queued items until they are investigated to work out what patrol they are from and why they haven’t processed (which is not easy cos there’s no patrol ID in a trackpoint file). The cases I recall all involved data queue items containing just a single track point as if they have been generated during the Stop patrol process. This might just be a bug report I guess rather than anything I can control with change of practice.

Hi Jeremy,

Thanks for this. This will be submitted as a ticket for review by the team.

Hopefully we can update on this issue in the near future.



Thanks Alex.
Here’s an example where the final trackpoint date/time is the same as the Stop message date/time. The trackpoint file was uploaded to Connect after the Stop message, so the Stop message so was processed before it in SMART.
Presumably if the trackpoint file had processed first the existence of that last trackpoint wouldn’t have caused the Stop message to fail.
Jeremy (3.6 KB)

1 Like