live-tracking.locusmap.app web page

[Andrew Heard]

@Andrew Heard Is it possible that you have been running some kind of simulation or using some kind of "fake" GPS provider?
Also if the GPS was disabled, it is possible that Locus tried to use your position based on Network provider e.i. your IP address and/or WLANs in your surrounding. If you use some kind of VPN or network proxy it could theoretically mess with your network location.
If you communicated with the server, it got some kind of position from your phone anyway. We have never supported any kind of "spectator" mode on the Android client, which seems to be what you are missing and what you attempted to do.

@milan.cejnar - thanks for checking - I was using "NoRoot Firewall" to block unwanted mobile data - just limit to Google & Locus - which I believe uses a VPN. GPS was disabled. Position is only based on GPS. I'm not suggesting a "spectator" mode. I didn't attempt to "live track" my position - it was only after friend noted I had moved across the world I discovered the strange "issue" myself.

[lor74cas]

@lor74cas
Hello, I wrote you an email through help desk 2 weeks ago (I hope it got through to you?). But it might be a good idea to share it here for others as well.
I tried once more after your report and finally hopefully found the cause of the problem. It should be fixed in the current version of LM Pro and the LT service should wake up correctly after connectivity state change.

Thank you I tested now and it works as expected.
In the previous test I think I did something wrong.
There is just a little thing that doesn't work properly: the fail/red count
I tested the LT, blocking the data traffic a lot of times, LT now stops and restart correctly, but the red count was set always to 1, the green one counts correctly.

[milan.cejnar]

@lor74cas
Great, thank you for trying out the patch. The error count makes sense actually with the current implementation. Since the track is not recorded to be sent to the server later, the live tracking service is actually doing minimal work required and awaits connectivity change signal from the system. No practical reason to refresh notification and do the extra work, although it might be a bit confusion. Maybe some offline state could be indicated in the notification.

@Andrew Heard
Ok, that firewall software seems to actually explain it. As I said, if you started live tracking even with GPS off, your "network" location was most probably used instead and sent to the server. I don't know, this is not really an error, but I have to admit that using a network location provider for this use case especially in the remote outdoor areas might not be very useful, maybe we should switch to GPS-only location source.