Randomly stops recording points

[stpr-dev]

I have been observing this behaviour recently, where the app randomly stops recording points. Today I confirmed that, I had the App on all day, I could see the persistant notification. Yet it randomly decided to stop recording the points. It initially was recording the points, but towards the end of the day it suddenly stopped doing so. I checked to see if the App was active before setting off from my work place, and I can confirm it was. But it recorded nothing. My battery was full all time, no issues with that.

Can you think of any reason it would display such weird behaviour?

General Information: App details: Version: 1.1.22 ; Source: F-droid OS: Cyanogen OS 13.1.2 (Android 6.0.1) Device: Oneplus One (aka A0001 aka Bacon)

[redfish64]

It may be that after the phone goes to sleep when TTT is not scheduled to collect points, it's not waking up when TTT tells it to.

The basic way it works is as follows:

1. TTT enables a wake lock and turns on GPS.
2. When TTT gets a GPS point or gives up, it will disable the wake lock and set an alarm to wake up the phone when it is scheduled to try and get another point.
3. The phone should wake up on schedule and TTT will start again at step 1.

If you turn on "Enable wake lock log" in Settings, and send me "/sdcard/ttt_wake_lock_debug.txt" when this occurs, I would be able to debug this better.

[redfish64]

I found this: http://stackoverflow.com/questions/5938213/android-alarmmanager-rtc-wakeup-vs-elapsed-realtime-wakeup

I have been using RTC_WAKEUP to wakeup the phone, which relies on the wall clock. According to the above link, this seems to not always work because the phone network can update the time unpredictably.

I'm switching over to ELAPSED_REALTIME_WAKEUP, which is based off the phone boot time, and should hopefully fix this. It's somewhat complicated fix since the code to determine when to wake up uses several variables that were based on wallclock time and they all had to be switched over to phone boot time, so I'm going to test it today and will release it tonight if I see no problems.

In the meantime, you can try and disable "Use network provided time" in your settings and see if that fixes it (along with enabling the wake lock log as I suggested above).

[redfish64]

The change I made seems to work, so I put it into v1.1.23, build 67.

You can monitor it here: https://f-droid.org/wiki/index.php?title=com.rareventure.gps2/lastbuild&redirect=no

[stpr-dev]

@redfish64 Ah bummer, I just realised that I had disabled the log for some reason. I will keep an eye out for it, and thanks for the update too! I will test this before and after upgrading to see if I can get something useful for you to work with.

[stpr-dev]

@redfish64

Here is more information for the OLD version (1.1.22).

I have been monitoring the log, just to verify what is going on. Here is what I found in the past couple of days:

Mon Oct 24 18:48:07 ADT 2016 releasing wake lock for sleep Mon Oct 24 18:49:34 ADT 2016 acquiring wake lock Mon Oct 24 18:49:34 ADT 2016 WARNING: gps desire manager has asked for more than allowed time, gpsTimeAvailable: 468773, desireManager.currTimeWanted: 480063 Mon Oct 24 18:57:34 ADT 2016 sleep until Mon Oct 24 18:59:00 ADT 2016 Mon Oct 24 18:57:34 ADT 2016 releasing wake lock for sleep Mon Oct 24 18:59:00 ADT 2016 acquiring wake lock Mon Oct 24 18:59:30 ADT 2016 sleep until Mon Oct 24 19:00:57 ADT 2016

Notice the warning message and the jump from 18:49 to 18:57? There are more instances of this in the log, ranging from a couple of minutes to several minutes or even hours. So there is some random occurances of events that leads to this warning and the gps points stops collecting, for seemingly random length of time (or maybe until we start the application again? Not sure). I am not sure what is going on here right off the bat, but I thought I will update it ASAP so that you can have a look at it and confirm stuff.

The new version is available on F-droid, if this is enough information for you to verify and/or work with, I can upgrade it. I do not mind waiting to upgrade and helping you out to sort this issue!

[redfish64]

I just found out there is a new way to set an wakeup alarm starting in 5.0 (Marshmallow) which is supposed to set an alarm which is more reliable, than the still very flaky AlarmManager.set()

I've been experimenting with it, and have encountered some weird race condition where the phone seems to be sleeping at the wrong time. Anyway, I'm able to reproduce your issue (or at least some issue like the one your speaking of), and adding to the log messages to hopefully figure out what is happening.

Thanks for your patience

[redfish64]

Actually that race condition that I thought I found wasn't. When I turn on GPS, the phone is ignoring my request to stay awake! I don't know why before, when there was a bug that made the wake lock was on all the time, the phone would honor it. But, now when I only use the wake lock for 30 seconds or so, the phone decides to ignore it.

I don't have a fix for this, but it only seems to happen when my phone is in airplane mode. So, I made a workaround, so my app doesn't think it left the gps on the whole time the phone decides to take a nap for an hour. (When this happens it won't use the GPS for several hours because it believes it used too much already)

I'll test it today, and if it works, will release it tomorrow.

[stpr-dev]

In the mean time, I will test 1.1.23 and let you know what I find.

[israel-lugo]

Just commenting to add that this happens to me too, on my One Plus Two, using TTT 1.1.22 (F-Droid build 66) on OxygenOS 2.2.1 (Android 5.1.1).

I'm attaching a ttt_wake_lock_debug.txt, in case it helps in some way. One event that I remember where I think you can see this happening on the log was on Fri Oct 21. I had GPS on and I forgot to turn tracking off after lunch, when I went into the basement (hint issue #49 ;-) ). In the log, you can see the warning from gps desire manager:

Fri Oct 21 13:55:25 GMT+01:00 2016 acquiring wake lock
Fri Oct 21 13:55:55 GMT+01:00 2016 sleep until Fri Oct 21 14:01:34 GMT+01:00 2016
Fri Oct 21 13:55:55 GMT+01:00 2016 releasing wake lock for sleep
Fri Oct 21 14:01:35 GMT+01:00 2016 acquiring wake lock
Fri Oct 21 14:01:35 GMT+01:00 2016 WARNING: gps desire manager has asked for more than allowed time, gpsTimeAvailable: 474517, desireManager.currTimeWanted: 480003
Fri Oct 21 14:09:35 GMT+01:00 2016 sleep until Fri Oct 21 14:15:14 GMT+01:00 2016
Fri Oct 21 14:09:35 GMT+01:00 2016 releasing wake lock for sleep
Fri Oct 21 14:15:15 GMT+01:00 2016 acquiring wake lock
Fri Oct 21 14:15:45 GMT+01:00 2016 sleep until Fri Oct 21 14:21:24 GMT+01:00 2016
Fri Oct 21 14:15:45 GMT+01:00 2016 releasing wake lock for sleep
Fri Oct 21 14:21:25 GMT+01:00 2016 acquiring wake lock
Fri Oct 21 14:21:55 GMT+01:00 2016 sleep until Fri Oct 21 14:27:34 GMT+01:00 2016
Fri Oct 21 14:21:55 GMT+01:00 2016 releasing wake lock for sleep
Fri Oct 21 14:27:37 GMT+01:00 2016 acquiring wake lock
Fri Oct 21 14:28:07 GMT+01:00 2016 sleep until Fri Oct 21 14:33:46 GMT+01:00 2016
[...]

After this time, no points were stored that day. I drove for 1h30 after work to the beach side, and I can see many wake and sleep messages that day, but no points in the GUI. I imagine it must be related to the desire manager thinking it's already had a huge amount of GPS time, when it really didn't.

I know for a fact that I didn't enter airplane mode. But I was in a basement without GPS reception for a few hours in the morning and afternoon.

A workaround that seems to work sometimes is disabling GPS on the Android pull down. I'm not 100% sure, but think TTT gets stuck less often if GPS is disabled, than if GPS is enabled but I'm in a basement.

A better workaround seems to be disabling TTT tracking, and re-enabling it. I try to do that after I've been somewhere without reception, but of course I forget to do it. Also, I have to enter the password everytime, just to disable or enable, so I'm lazy.

Something happened also on Sat Oct 22, between ~16h40 and ~18h45. I have points from before that time, and after that time. During that interval, nothing. Interestingly, this time there isn't any gps desire warning:

Sat Oct 22 16:45:36 GMT+01:00 2016 sleep until Sat Oct 22 16:47:13 GMT+01:00 2016
Sat Oct 22 16:45:36 GMT+01:00 2016 releasing wake lock for sleep
Sat Oct 22 16:47:15 GMT+01:00 2016 acquiring wake lock
Sat Oct 22 16:47:23 GMT+01:00 2016 sleep until Sat Oct 22 16:49:01 GMT+01:00 2016
Sat Oct 22 16:47:23 GMT+01:00 2016 releasing wake lock for sleep
Sat Oct 22 16:49:02 GMT+01:00 2016 acquiring wake lock
Sat Oct 22 18:44:11 GMT+01:00 2016 IntentTimer constructor
Sat Oct 22 18:44:11 GMT+01:00 2016 acquiring wake lock
Sat Oct 22 18:44:14 GMT+01:00 2016 sleep until Sat Oct 22 18:46:33 GMT+01:00 2016
Sat Oct 22 18:44:14 GMT+01:00 2016 releasing wake lock for sleep
Sat Oct 22 18:44:18 GMT+01:00 2016 acquiring wake lock
Sat Oct 22 18:44:18 GMT+01:00 2016 sleep until Sat Oct 22 18:46:33 GMT+01:00 2016
Sat Oct 22 18:44:18 GMT+01:00 2016 releasing wake lock for sleep
Sat Oct 22 18:44:18 GMT+01:00 2016 acquiring wake lock
Sat Oct 22 18:44:18 GMT+01:00 2016 sleep until Sat Oct 22 18:46:33 GMT+01:00 2016
Sat Oct 22 18:44:18 GMT+01:00 2016 releasing wake lock for sleep

Just at 16h49 a "acquiring wake lock", then at 18h44 something about "IntentTimer constructor" and the wake lock again. It's possible that I turned off tracking by mistake, but I doubt that as I actually really wanted tracking at the time. I'm a photography enthusiast and I was out taking photographs by the shoreline cliffs, which I planned on GPS tagging later on. Of course I still have the general area on points before and after, but it would've been nice to have the actual track I went through. In any case, I know for a fact that I didn't activate airplane mode.

Does any of this help at all? I have an upcoming trip to visit another country for the first time next weekend, and I really want to have an accurate GPS trail of my trip. I could use some other GPS tracker temporarily, which I know would work. But TTT really is the best, with the maps and timeline browsing etc., so I'd love to use it.

Regards, Israel

[israel-lugo]

I'm a photography enthusiast and I was out taking photographs by the shoreline cliffs, which I planned on GPS tagging later on.

Actually, on this subject, a quick side question: is it possible to export a GPX file of a limited time range?

My use case is: I go travelling somewhere, take lots of photographs with a couple of cameras, and later I want to tag my photos on my PC. I would select a time range in TTT, export it to GPX, then use the GPX file with my normal photo cataloging software, to geotag the photos.

I know I can export (backup) the entire database, but I did not notice a button for a custom export. Is there a way of doing this, that I did not notice?

Of course, I could just export everything and then edit the GPX file with a text editor to delete the entries I don't want, but that's a bit of work...

[stpr-dev]

@israel-lugo

My situation was quite similar, I was in my office (or other places with no GPS reception inside the building) when I noticed this issue. I got out of my office after several hours of no GPS signal. Since you mentioned that you were in a similar position, it could very likely be that if you are in a place with no GPS reception for an extended period of time, something like this happens. @redfish64 What do you think of this?

[redfish64]

This latest release seems to fix the issue for me, for the most part. However, when I go into airplane mode the phone still likes to go into idle mode regardless of whether I turn on wake mode or not.

I did the following:

1. For M class phones and above (Android >= 5.0) I am using a new special method to set a wake timer that is suppose to handle idle. It doesn't actually work all the time, but it's better than before
2. When a phone went into idle mode when I wasn't expecting, it screwed up the stats which are used to determine what percentage of time the GPS was running. What would happen is I would turn on the wake lock and GPS and wait for 30 seconds, and then the phone would go idle during that time and wake up a few hours later. The code would incorrectly assume that GPS was on during the whole multi-hour period. This would prevent it from turning the GPS on again, because it thought it was way over the percentage of time asked for by the user. This may be your problem, @israel-lugo but I am not sure. It might have been going idle during those times and messing with the GPS stats.
3. I added a lot more debugging info into the log.

Build 68, v1.1.24

Of course, you can monitor it here: https://f-droid.org/wiki/index.php?title=com.rareventure.gps2/lastbuild&redirect=no

[israel-lugo]

Thank you for your work, @redfish64. Your explanation makes sense, let's hope the new alarm method makes it better. I will download the new version and try it.

Regards, Israel

[israel-lugo]

Curious, the build has already been done successfully a few hours ago, but the F-Droid store still reports version 1.23 (build 67). I'll wait, I suppose.

[stpr-dev]

@redfish64

Here is an update for the new version. The log appears to suggest that it is facing a similar problem

ttt_log_2016_11_1(1).txt

There are similar instances of such thing, however none of them jumped by as much.

Also, a strange issue occured where I was out of my office, but the GPS reading was not recorded for several minutes.

ttt_log_2016_11_1(2).txt

I checked to see if the GPS button on the app was available, and it suggested that it was getting a signal. But no points were recorded. I had to restart the app (see the intent timer construct at 13:41:56? Thats when I restarted the app and it was recording again).

Also, upon inspecting the log, I can see several warnings during that period, not sure why.

[stpr-dev]

@redfish64

I noticed you released an update, here is more information regarding that update.

The good news is that I have not seen the random jumps in the time for recording points so far (at least the log indicates it) as compared to the previous cases.

However, the message that appeared (about GPS desire manager asking more time than allowed) still appears every now and then. What is with that message? It seems so confusing to me. Why does it occur?

If you look at the attachment, the appears at 9:38:05, appears for 3 consequetive "blocks" and disappears. Then again in some other location for a couple of times, and then disappears. It looks weird to me.

ttt_wake_lock_debug_2016_11_08.txt

[stpr-dev]

@redfish64 After quite a while, it happened again yesterday. The first time for me since you pushed the new update. Unfortunately, I had disabled the log, since I thought the issue was fixed. But I suspect that it has to do with the same warning message that was being displayed previously.

[TjrGithub]

I'm still seeing this problem with the latest FDroid release. But it might have a different reason: Ridiculously long GPS time-to-first-fix, see #60.

[vic42]

It happened to me on January 17th with the most recent F-Droid version. Suddenly stopped recording and i can't get it to record again. I have a good GPS fix, yet no recording after January 17th. I can view the data up to that point (~3 months) without problem. I have that little frog logo "GPS collecting is active" Is there anything i can do apart from re-installing?