IOS client 9.6.5 stopped tracking
I see the same but why this happen also with Offline buffering: off and why the client than uses such a old outdated timestamp
To me it sounds like it got stuck on uploading some previous position and it takes a long time for whatever reason.
When I first observed this behavior, my initial assumption was that the client-side queue might be filled or blocked for some reason.
To test this, I disabled offline buffering and restarted the iPhone. While I was not certain whether this would fully clear any existing queue, I wanted to rule it out as a potential cause. However, the behavior remained unchanged.
I then deleted the app entirely and reinstalled it, under the assumption that this would remove all locally stored data and reset any internal queues. Despite this, the issue persisted and the behavior did not change after reinstallation.
I tested the setup against a newly created server, and the “Busy with previous request” issue does not occur there.
The testing is not yet complete and has so far only been done using “send position”. However, even with this limited test, the UI updated immediately, unlike on the old server where outdated timestamps were still shown. This suggests that the issue may be server-related.
What I find unusual is that an Android device with identical settings worked correctly on the old server.
I will continue testing tomorrow and may also try some optimizations or adjustments on the MySQL database.
Traccar is being affected by iOS background throttling. The app receives new GPS data, but the server sees outdated positions because CFNetwork queues or delays HTTP requests. Android does not have this problem, thus it functions well.
Even with offline buffering turned off, quick updates are delayed on iOS 17+ due to the restricted background networking. It is often resolved by lowering the frequency of requests and using large geographical shifts.
Thanks for the info.
Just to clarify, this setup with the iPhones and the server has been running smoothly for quite some time, including through iOS and server updates. Overall, it’s been very stable.
As mentioned before, there were no updates to the app, iOS, or the server around the time when the tracking started to stop.
I’m currently testing with a new server using the same configuration. The main difference is that the MySQL database is mostly empty.
With this setup, I don’t see the “Busy with previous request” message in either the “send position” process or the app logs.
Because of that, it seems possible that the database (its size or state) could be contributing to the issue on the client side.
There may be an edge-case timing issue in the handling of client requests, where Android appears to be more robust than Apple.
Hi Anton, thank you for your previous support..
After further testing, it appears that the issue is related to the MySQL database. When using a relatively new (almost empty) database, I no longer see any “Busy with previous request” messages, even with the same iOS app settings that I used previously.
The existing old MySQL database itself seems to be working correctly, at least when accessed via an Android client.
Based on this, my conclusion is that the iOS client is more sensitive to server response times, which may be affected by the larger database size on the server side.
Do you have any recommendations beyond the optimization settings described here: https://www.traccar.org/mysql-optimization/
My use case requires long-term storage of tracking data (approximately 10 devices over several years), so regular historical cleanup is not an option. In this context, would using TimescaleDB be a better approach for long-term data storage?
I think TimescaleDB is definitely a better option, but you should also debug the query. Why does it get stuck?
I see a lot of this:
Which indicates that some other request is already in progress.