Messages

.. aaaand the problem I reported is fixed now. Thanks! :-)

.. and I'm sorry but v1.9.6 still has my problem as well :-)
I open Locus, start recording,  hit home button, open locus,  pause recording, hit home button: GPS off. Then I turn off screen, turn on screen and GPS is enabled even before unlocking the phone...

:-(

Do you have any error messages in /sdcard/Locus/logs/ around that time?
On my DHD, both "Always" and "While recording" (the latter only while recording, of course) produces NMEA files in the given folder.

It is however saved in the folder /sdcard/Locus/data/nmea (notice the lowercase). Is your folder lowercase as well? And if so, is that folder writable? Maybe you want to remove it and let Locus recreate it (just guessing)

[start recording]

I'm sorry to report that the issue isn't entirely fixed yet :-( Not in 1.9.3, not in 1.9.4
However, I can see the improvement :-)

• Start Locus, hit home button, screen off, screen on: GPS stays off until you activate Locus again (jay! Fixed!).
• Start Locus, start recording, hit home button: GPS stays on (of course). Go back to Locus, pause recording, hit home button, screen off, screen on: GPS is enabled (which is not the desired behaviour)

Since the update to version 1.9.2 ME, Locus got this behaviour:

• start Locus
• Enable GPS
• Hit home button, so Locus goes to background without quitting it
• After a small amount of time, you'll see the system GPS notification icon disappearing and GPS being disabled (good! Locus isn't active and I have the setting "Disable GPS" enabled)
• Hit the power button (screen off)
• Hit the power button again (screen on)

Even before you actually unlocked the screen, you'll see the system GPS notification icon appear again and even though Locus is still in the background, it has just activated the GPS.

Open Locus again, then hit the back button. Confirm that you want to quit Locus. The GPS icon disappears. Screen off, screen on and the GPS stays disabled.

I did notice this behaviour before as well, didn't pay attention to it though.
I'll run some tests as well

To avoid any confusion, this is the app I'm talking about:

//https://market.android.com/details?id=com.eclipsim.gpsstatus2&feature=search_result

I know :-)
Tried several times with gps status, no interference...

I had only 23h 12m recording, a full track recording and a 46MB NMEA file, but Locus is just fine, not a single problem.

OK, 45 hours is pretty nice number I'll release it with actual state and if there will be some troubles, I'll still be working on it. But looks promising. Thank you for excellent testing!!

Thanks for following this up so quickly (as always )

As for me, 74km, 3120 points, 11h and 45m recording, 13MB NMEA file. Not a single problem, so I'm extremely satisfied.
Didn't go to the supermarket though ;-)

No, really, I didn't check using GPS status or the satellites status in Locus, will do that tomorrow.

However, this is a major improvement!

Just saying: recording was still running, Locus was still up and running.

I killed it  :twisted:

But the result was not as I expected it. It seems that the build in application manager in 2.3.3 kills everything, so the services were killed as well: Locus gone, "Track record" notification icon gone, GPS signal gone.
Damn :-)
So I relaunched Locus: Track Recording icon re-appeared, recording was paused. I restarted recording and now I'm not touching it before this evening...

Everything's still fine here. Of course, I paused recording during the night, so GPS was inactive anyway.
Today, I'm going to keep it recording all day, let's see what's happening.

I'm excited. Current results are very promising.
Started the recording at 17:03:04 and my trip must have ended around 17:20 local time.
I didn't stop the recording, kept Locus in the background and used my phone minimally.

At 20:10 I opened Locus and paused the recording. It was only then that it appeared to me that Locus itself was still up and running! The track was complete, but of course, it was only 20 minutes of recording.
Then, I checked the NMEA file and the last entry was at 20:10:51!
Ten minutes later, I restarted recording, one minute later I paused it again and checked the NMEA log. The entries were added to the log.

Now I'm pausing it and I'm planning to restart it tomorrow morning.
Good job!

Oh, and I have the impression that Locus is much more battery efficient now. So I'm twice as happy :-)

When creating a new category, enter a name with a ' (quote) in it and save it.
It won't appear in the list, but Locus will generate an error log which gives away some nice SQL statements  :twisted:

I'm filing a new report for these two, just minor bugs.
When MyTracks recording is used, it appears to me that Locus looses its grip on the MyTrack recording status, mainly because Locus gets killed while the MyTracks service keeps going.

• MyTracks recording is started within Locus and Locus is sent to the background. After a while (say: one hour, but you can manually kill Locus as well, it has the same result) you launch Locus again. The recording bar will give you the option to start recording, although recording is still running. You can hit the "start" button without any problem, but an error log will be created
• MyTracks recording is started within Locus. Start MyTracks application itself and stop recording using MyTracks. Return to Locus. It didn't notice the recording was stopped. Hit the "Stop" button. Locus Force Closes (stacktrace in screenshot, couldn't export it as text)

I don't know if this has its effect on the MyTracks recording as well.
I've been thinking about creating a new bugreport for this, but I have a feeling that this could be related, so I'm posting it here.

If I use the (less preferred) MyTracks method to record a track, this is what I see (although further testing is required since I don't fully understand what's happening)
I started the tracking at 9:10 local time and didn't touch my phone until 10:07. The MyTracks tracking icon wasn't there and neither was the GPS signal indicator. I opened Locus (it started from scratch) and showed me that recording was stopped. So I started it again.

At that point, 10:07:04, there's a log file created:

Code Select Expand

----------  May 28, 2011 10:07:04 AM  ----------
TAG:MyTracks
MSG:onServiceConnected()
TRACE:java.lang.IllegalStateException: A track is already in progress!
at android.os.Parcel.readException(Parcel.java:1330)
at android.os.Parcel.readException(Parcel.java:1276)
at com.google.android.apps.mytracks.a.a.a(L:171)
at menion.android.locus.core.a.b.a.onServiceConnected(L:123)
at android.app.LoadedApk$ServiceDispatcher.doConnected(LoadedApk.java:1098)
at android.app.LoadedApk$ServiceDispatcher$RunConnection.run(LoadedApk.java:1115)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4196)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)

Indeed, when I stop the recording, I can see that there's just one file.
However, tracking stopped at 9:54:37 (maybe because I entered a building by then) and restarted at 10:07:59 (same trackfile)

As said, maybe this is because of the same issue.
And although I hope the Locus tracking is reliable soon (so that I can use that again   ), you might want to know about this one as well :-)

That looks good indeed. 5 seconds of missing tracks is not so bad.
Its strange however that services are killed, even when not under extreme memory usage...

Just for your information, although I'm sure you already know this: on Android Developers there's an interesting paragraph on Process Lifecycle that says:

A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
[/list]
I haven't created a service myself yet, but it might be a thought? :-)