Stopdetection timeout issue starting from version v10.1.3

Activity detection while moving is noticeably better and now reacts almost in real time (which is really good). When a driver or cyclist stops, the recognized activity switches to still right away, which starts the 60-second stop detection timer.
However, 60 seconds is shorter than a typical traffic light stop, and this creates a problem. Exiting stationary mode and resuming movement tracking takes much longer than entering it.

Scenario example:

1. The user is driving and stops at a traffic light for 2 minutes.
2. After 60 seconds, the app switches to stationary mode.
3. One minute later, the user starts driving again.
   It takes about 5 minutes for the app to return to moving mode, so no location updates are sent during that time.

Before this update, this was rarely noticeable because the old activity detection was slower and the app usually stayed in moving mode through short stops. Now that detection is much more accurate, the short timeout triggers much more often.

Suggestion:

1. Simple soution: Increase the default stop detection timeout from 60 to 300 seconds ( I think this is a resonable period)

2. More advanced (maybe in the advanced settings) : make it auto scale propotionally to the time the user has been moving in with a configurable minimum duration of x seconds and maximum stopdetection timeout of y seconds, to avoid stale locations during short stops.

This is an issue starting with version 10.1.3

Can you explain your first suggestion. How does it fix the problem?

It increases the timeout from the currently set stopdetection period of just 60 seconds to a more reasonable one that is 300 seconds ( slightly more than the average duration for most traffic lights in the world) so this way, before the device goes into stationary mode in a traffic light, the recognized activity won't be still anymore and traccar will continue being in moving mode

Or maybe you have a better way to resolve this issue. What do you think the ideal way to resolve this issue be?

Ideally, Also maybe have different stopdetection timeouts for different activities. For example for walking 60 seconds is ideal , however for driving or cycling 300 seconds is more reasonable

Can you please provide logs.

Please try version 10.1.5.

Here are the logs for when I noticed this issue on version 10.1.3

https://wormhole.app/yyav8r#jNQ2Z8qGKBwEhuGGPzWXvA

I just updated to 10.1.5 and will try it out, but why did you stop sampling activity often while in moving mode which was honestly awesome as it was able to pickup on the device's current activity in real time and engage stop detection when going stationary instead of just updating the stopdetection timeout period to resolve the issue?.

Would you mind if I may ask please, isn't the frequent activity sampling is mainly how you were able to fix the GPS being always stuck on, on geofence exit without the transition api reporting movement or when going stationary and transition api doesn't report going still( for reference https://www.traccar.org/forums/topic/gps-stuck-constantly-on-when-stationary-on-some-devices-logs-provided/ ).

And now without the frequent activity sampling while in moving mode, I am afraid that bug might resurface ( hopefully I am wrong here).

I will try to test it in real world scenarios on as many devices as I can and collect data and report back within the upcoming couple of days. Thanks

It shouldn't resurface. This is just a more narrow fix for the original problem.

So far, all devices I tested 10.1.5 on, all working as expected with no issues at all. So it appears that this issue was resolved too. Woooohooooo. Will keep on testing it and report back in a couple of days. But initial tests are so far so good. Thanks for your efforts and your timely fix to the issue

Thanks for the update.