Device State frozen in time, after receiving corrupted date/time stamp
Your guess is correct. Because the time of invalid record is in future, Traccar considers it to be the "lastest" update.
To fix the problem you would have to re-create the device, or manually remove invalid data from the database.
If your device regularly reports such data, you can enable filtering in the server config to ignore messages with future time.
If my assumptions are correct, then I guess the server needs to ignore a received message as 'invalid' if the embedded Timestamp differs by the Timestamp of the data packet by more than X amount of time. And send a WARN to tracker-server.log. The 'X' could be defined in the default.xml I hope this helps.
Our posts just crossed.
If I filter out messages with future time, won't that stop any future location updates being received?
manually remove invalid data from the database.
Where would I find this data?
Filtering works exactly like you described in your comment.
To manually remove it from the database, you need to remove it from positions table first and then remove reference to it from the devices table. Don't forget to restart the service after doing the changes.
I´ll look at Filtering later.
My attempt to surgically remove invalid data has failed. I've been trying to edit the raw database.mv.db with a .TXT editor (after stopping the service). I´d searched for strings "7028290952", "2072-04-29" both in ascii and hex. Couldn´t find anything matching. I´m a bit wary of hand-editing a .db file in case I break it.
I don't understand "positions table", "devices table"
Why would you use a text editor to edit database? You would almost definitely break something. You need to use a proper JDBC database editor for it.
Because you suggested it!
manually remove invalid data from the database
I picked up my nearest textfile editor but neither string “7028290952”, “2072-04-29” was found.
What's a JDBC database editor?
I didn't suggest to use text editor for it. I guess this option is not for you. You need some technical expertise to do it.
OK, until I have the required technical expertise I can't manually remove invalid data from the database. So to resolve the problem I'm left with the other option you mentioned earlier:
Anton:
enable filtering in the server config to ignore messages with future time.
OK
Anton:
Filtering works exactly like you described in your comment.
in response to..
Marc:
I guess the server needs to ignore a received message as ‘invalid’ if the embedded Timestamp differs by the Timestamp of the data packet by more than X amount of time. And send a WARN to tracker-server.log. The ‘X’ could be defined in the default.xml
Question: Is this filtering implemented in Traccar?
If so, how is it enabled? I can't yet find anything relating to this in the default.xml config. I presume when active a WARN message gets written to Log.
Check this page:
I found in above page the 7 keys: filter.xxxxx They seem to be what I'm looking for.
However none of these keys appear in my C:\Program Files\Traccar\conf\default.xml
Maybe they were omitted from the default.xml?
Should these keys be added to the traccar.xml (or any other user custom config)?
You have to add the keys that you need to traccar.xml file.
So this filtering is not a standard feature of Traccar?
If it's required to be added as a custom feature a How-To guide is required. If I post this here on this thread myself then be aware it may be some time before I work it out, because I will need to test it works first with an emulation tracker to simulate corrupt data.
The tracker icon was moving on the map this morning but then it froze and stayed in the same location all day. During the rest of the day the tracker continued to send valid locations but the server didn't display any further vehicle movement.
It seems the server only notices locations that have a later time stamp than the latest received, and ignores any earlier time stamped data.
I would guess there's no 'feasibility validation' of timestamp implemented in the server.
Here's the messages that caused it: (with the corruption highlighted)
And the transcript in full:
It's my guess normal operation will resume after the year 2072!