Delayed web app locations
It sounds more like device is uploading some buffered data.
The first way to validate this is ensure your preferences include showing Server Time, Fix Time, and Device Time. That will confirm if the data indeed arrived in real time. If the device time is old and the server time is new, it's a buffered upload from the GPS tracker device. Depending on tracker hardware vendor, the way the devices upload buffered data can be odd. I tend to go with "oldest first" on my Teltonika trackers so that the stsatus doesn't behave weirdly until it catches up.
Second to this, the system uses WebSockets for GUI updates and if your server is behind a weirdly configured reverse proxy, this can affect it.
Last, if you have multiple people logged into the same Traccar user account, my experience is the Websockets get weird and the device status can get really out of sync. If you have multiple people monitoring a device, ensure they are all logged into their own account; just add the Device to all of the accounts so they can all see it.
I think you're right that the unit is the problem. The other thing I'm seeing in the logs is a lot of connects and disconnects around the following error:
2025-10-03 06:36:53 INFO: [T662e1d96: gt06 < 41.82.171.69] 78780c69190a030531220103155c5a0d0a
2025-10-03 06:36:53 WARN: [T662e1d96] error - readerIndex(17) + length(1) exceeds writerIndex(17): UnpooledSlicedByteBuf(ridx: 17, widx: 17, cap: 17/17, unwrapped: AdaptivePoolingAllocator$AdaptiveByteBuf(ridx: 17, widx: 17, cap: 2048)) - IndexOutOfBoundsException (... < Gt06ProtocolDecoder:632 < *:1578 < ExtendedObjectDecoder:73 < ... < WrapperContext:102 < ... < WrapperInboundHandler:56 < ...)
2025-10-03 06:36:53 INFO: [T662e1d96] disconnected
Seems like it connects, tries to send something, traccar throws an error, and disconnects the socket? Then the unit has to try and reconnect before sending any position data? Maybe that's why it is storing/sending the buffered data. Guessing in the dark...
Doing some more searching on the forum, and others have run across this error. Not a part of the standard GT06 protocol, but does contain valid date/time information. See https://www.traccar.org/forums/topic/decoding-error-0x69/
Matches the data above.
7878
0c - 12 bytes
69 - Time stamp message
19 - 25 year
0a - 10 month
03 - 03 day
05 - 05 hour
31 - 59 minute
22 - 34 second
etc...
Would it change the behavior of the device if the packet was acknowledged by the server as valid (even though we don't know exactly how to decode it)? We know the length is consistent.
Looks like there's a conflict with some other format. Do you have the protocol documentation for your device?
I don't. It's a GT06, and everything processes correctly using that protocol, except the 0x69 message.
I see in the source code (Gt06ProtocolDecoder.java) that 0x69 message exists in the protocol already (MSG_WIFI_2). Is the GPS unit maybe sending an incorrectly formatted 0x69 message?
It's probably reusing the same type for something else. That's why we need documentation.
Recently noticed a problem with certain devices not showing their correct locations/timestamps on the web app or iPhone app. I haven't nailed down the cause or how to recreate the problem, but I've seen it on a few devices now. The icon shows as valid fix, but timestamp of the fix is minutes or hours old. Then, as I watch, every three seconds or so, the location will progressively update to the next fix, getting slightly closer to real-time reporting. Once the device is reporting real-time, it seems to stay that way. I get correct location updates within 6 seconds of real-time. I've linked a video of it happening: https://drive.google.com/file/d/1Ek4LJrFCRgZV0V-Whg-I_A8ogdGi_cR4/view?usp=sharing
If I look in /opt/traccar/logs/tracker-server.log, I see the reports from the device show up on time as expected. Seems like somehow the web client isn't asking for the correct data or maybe the writing to a database isn't happening real-time?