Messages

@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.

@lor74cas The fix should be there and it should work correctly now, does it not?

@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.

@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.

Regarding unlimited session timeout usability problems we will probably limit upper bound to some more sensible limit like 1 or 2 weeks, at least until more mature group management is in place.

And by the way, web is still not fixed the way we would like to. We unfortunately have to find somebody else to fix it, since our current contractor is apparently not up for the task.

@Andrew Heard
Hello and thank you for letting me know. So I have just double checked and your data are no longer in the DB but are still available through our web API. That means one of our caching layers have failed to evict the data after the internal timeout for some unknown reason. The fix is not trivial and I will not be able to fix this right away (I will create bug report though). That means, that unlimited session time option is buggy right now, in a way that old unwanted data from old devices or LM versions get stuck and the system was not designed to be able to remove them in any simple manner.
I am very sorry about this, we wanted to add the feature but did not think through all implications when using for long time in a single stable group.
In the meantime you could create a new group or set the group session timeout to some of the available limited values. Of course we still confirm with the GDPR regulations and I could delete your LT data if you requested but that would mean deleting all your groups and your internal LT profile as well, which would make the data inaccessible,  but that is probably not very helpful right now.

As for the locale, I must admit that there is something wrong there then. Our locales work ok and we expected that the front-end framework will handle locales correctly out of the box. I will have to report this to the company doing the front-end for us. Thank you.

@Andrew Heard
I have deleted both positions from the DB, they should disappear from the system within an hour.
Actually to remove your position, it should be possible to just remove the group from the active groups of the profile while the LT is running (no need to delete the group completely). I am not even 100 % sure and I am the developer, so it is not something the user should be expected to come up with
To be honest, this is an "unexpected" side-effect of enabling the possibility for group locations to be persistent - the positions always seemingly disappeared before as each group had a timeout. Even setting the group's timeout and then switching it back to unlimited will not help.

So simply put, there is no approach to do that when you share your position to the group with unlimited position timeout, which is not exactly user friendly. There indeed should be some method to do this. Unlimited time groups are not used that much (67 so far) so you are the first one to report this logical inconvenient consequence. Sorry about that. I will write it down as an improvement/bug to be solved.

As for the date, we will not be able to help even after the fix. The date should be formatted according to your system's locale and I would expect other webs or apps to be using this format too on your device. We cannot enforce e.g. European locale on other users worldwide which might be unusual for them. There would have to be a special settings in you profile to select the prefered date/time format.

@lor74cas
Hello, I did not want to bother you with the help desk unnecessarily. It is just that I kind of missed the problem previously and did not try to reproduce thoroughly which was my personal mistake. I am sorry about that. The help desk just helps me to organize problems better and resolve them separately, especially because there was a lot of confusion and various errors concerning the LT web.
Anyway I tried to replicate again while locking the phone during the connection loss and could finally reproduce with my Samsung phone. The fix should be out with the new app version in a few days.

@Andrew Heard
Hi, I have checked the backend database and I can see the problem regarding your two positions. One position was recorded by the Locus Map Free and the other one by the Locus Map Pro. They are technically two separate clients due to some implementation details even when running on the same phone and with the same account. Leaving the group LM Free should hide your old position. Alternatively I could delete both last recorded positions on the server if it bothers you.

Hello guys,
sorry for the delay and no news. We have problems with the company which should have made the fixes and update but they are communicating again and promised to fix couple of issues.

Please if you have any problem related to the core LT functionality which can be reproduced in Locus Map directly (ie. not just concerning the web page itself), report it as a bug on our help desk so that I could get more information like your LT group identification and your Locus account info and solve the problems one by one.

@Andrew Heard
As for seeing your position multiple times, are you really using the same Locus account and the same Android device? Has the device been factory reset or rooted in the meantime? Or was the subscription really the only thing that has changed? If that is the case I would like to know (by a private email or PM) the name of the group and your email address that is linked with your Locus account if possible, thank you.

@lor74cas
I could not reproduce the behaviour but I will have to look again if you could reproduce it consistently.
You are right that the expected behaviour of the LT should be to increase the error count when there is no connection during the expected position refresh. But at the moment the actual behaviour is to don't even try if there is no Internet connection so that is why the numbers do not increase at all and that is not necessarily a bug (depending on your expectation). Still the position should update as soon as you connect to the network regardless of the app state, that indeed seems like a bug if that happens.
Again if you could please create a problem in our help desk, linking this topic so that we could solve it separately as it does not seem to concern the new LT web page problems.

Thank you

@raziel.trb@gmail.com
Hello, yes, this feature is still missing unfortunately. I want to have it implemented by this time but there are other issues with higher priority that I need to attend to. Sorry about the delay but I cannot promise you any specific deadline for this feature yet.

@slarti76
The add-on is still actively maintained and there was a small update not that long ago with added support for the new Galaxy Watch Active and with some fixes related to the unwanted add-on auto-starts.
Though I have to admit that active development of new features has a bit lower priority since beginning of this year due to workload related to the Locus Map 4 and Locus GIS release which are both expected later this year.

@lor74cas Hello, I am sorry about that, I have this problem in my task list but the service seems to be working reliably at the moment and there are no other reports regarding this specific issue. That does not mean anything and I will definitely investigate but I have set it to be a lower priority than some other tasks which is why it is taking a bit longer.

Regarding the problems with new web pages, we actually have problems communicating with our contractor and therefore we are unable to solve it at the moment, but we are very much aware of the situation.

Again, sorry about all the trouble, but I think the core LT functionality is pretty solid although I cannot dispute against that there are some major incoveniences at the moment.

Best regards
Milan

@Andrew Heard Thank you for mentioning this, it is true that private groups can set the "time out" to longer time.
But @lor74cas is right, this seems like a bug and increasing the time limit will only mask the problem somehow. I will add to my live tracking issues to solve.

@lor74cas Might only be a bug on the web, will have to try with two phones. The live tracking not reporting any failed transmissions might not be a problem. If there is no connection available Locus will notice this and postpone the attempt until the connection is available. The same should apply with GPS I think, so there should be no attempts to send the position until GPS fix is available.
But I would expect that as soon as a GPS or a connection is available there should be an attempt to synchronize position immediately (if last scheduled attempt had already been missed). So this is definitely not intended behaviour.

@lor74cas
Hello,
thank you for the report, this is indeed not wanted behaviour, your position should reappear as soon as you enable the data again and send the position update. I will try it out.
By the way the time limit in the public group before disappearing should be around 10 minutes. For private groups this time limit can be changed by the group owner.

Hi,
so the behaviour was a bit buggy and it can still happen sometimes, but in the majority of cases this should be fixed and Locus Map should not start when the watch is reconnected if the add-on is not running.
Also if this happens in some rare circumstances, the Locus Map will hang around for around 2 minutes, doing pretty much nothing and then turn itself off again (this should have actually worked even with the previous version, no need to turn it off manually)

Hello,
thank you for reporting this, it is definitely and unwanted behaviour. I will have to investigate how this could be fixed.
Best regards
Milan

@tapio Hello, I could not reproduce the error unfortunately If you will find the time to send the log I would really appreciate it and it would really help to solve the problem. Have a nice day.