You have to look at the data to understand why it's not recognized.
We examined the database, the messages look identic to me, no movement for a period longer than minimum parking time, speed is "0", motion switches from "true" to "False", etc. But some trips are recognized, some not.
E.g. this one is not recognized, port 5027
What time are we looking at? Also you say motion switches, but I don't see motion on your screenshot. Instead you highlighted digital input value.
Sorry, now with headline.
It´s the fix time, the digital input value comes from the device´s motion sensor, correlated to that in the reports "Motion" is recognized correctly as "yes/no",
Digital input is not the same thing as motion attribute.
That is clear, what I meant is, that the motion detector of the device and the motion detection of the server show the same values, most of the time, both see that the device is in motion.
To come back the other question: is there a mechanism to prevent overflow?
I have no idea what you mean by overflow. There's no such thing. If trips are not detected the way you expect, you need to look at the data, as I mentioned earlier.
Sorry for not being clear here, English is not my native language.
We´re digging the data but do not find any reason for the behavior.
As described, we import the data, ten thousands of messages in a short period. Could it be, that that huge amount of data doesn´t give the system enough time to recognize start and stop correctly? If I understand it right, start/stop is recognized while the data is coming in, not in a process afterwards. That is what I meant with "overflow", one of our attempts to explain the results.
Maybe this is a case where we need paid support from your team.
It doesn't matter how much data you have in a short period of time. Unless there's some problem with saving that data, it won't affect reports. That's a wrong direction.
If you want paid support, feel free to email us. Then maybe we can look through the data for you.
Hi all,
We would like to send archived messages from various devices to our Traccar server so that we can also view previous trips. We send the messages separately, but in large numbers.
The import works, but some of the trips are not recognised, even though the messages are stored correctly in the database and the report.trip... configurations are set to the default values. Could it be that the large number of messages is causing an overflow? Is there a queue to prevent this? Can we make any adjustments to ensure that the trips are recognised correctly?
Thanks in advance, Peter