Messages

And yes, I too would have expected Locus to pick up the Locus directory on the external SD, which definitely was accessible (browsed it with a file explorer). Strange indeed.

I use Siyah's kernel, and with the fixing update, he mentioned that he'd forgotten some umount during init, which was causing issues with some ROMs. I use the Lite'ning one, which was obviously affected. I don't know what that ROM may be doing special during boot and am not currently in a position to investigate. ;-)

Menion, stop that: it's turned out it was an issue after a kernel update (which however strangely only seemed to affect Locus). Things work again now.

Sorry about the noise, and thanks for your support! :-)

You sure changing the order will work, as the external SD is mounted on a sub-directory of the internal one?  I'd expect that mount to be inaccessible if "/mnt/sdcard" is mounted later on.

In any case, thanks for quickly looking into things! :-)

The internal SD path is "/mnt/sdcard".  "vold.fstab" is attached.

Deleting the "Locus" folder on the internal SD results in it being recreated, already tried that. ;-)

Hello,

On my ICS SGS2, I used to have Locus's data directory on my external SD card ("/mnt/sdcard/external_sd/Locus"). As of the latest update, however, Locus ignores that location and creates a new directory on the internal SD instead. As the internal SD is VFAT, I also can't simply symlink the actual directory there.

So, my question is, has there been some intentional change to how Locus handles its data directory (nothing in the changelog), and how can I get it to use the external SD again?

Thanks again.  Your dedication is truly outstanding. :-)

Was that already in Locus prior to my request, or did you add this just now?  It's great in any case.  Thanks!

Hello,

When NMEA logging is enabled, Locus will currently write a single NMEA file per day (named after the date), even when recording separate sections (i.e., stopping track recording intermediately and recording another track later on the same day).  This will yield an NMEA log with gaps, and if I want to put the logs to use to, e.g., evaluate the individual sections, I'll have to split the file manually.

Would it be possible to change this behavior in such a way that a separate NMEA log is written per recording?  Locus might, for example, suffix the file name with an incremental number.  You might even choose to start adding that suffix only if the suffix-less file already exists, which would keep the current naming scheme for the first (and possibly only) track per day.


Thanks,

Marco

Hello,

I've found that Locus will hang when I stop track recording via the widget and select "Delete" on the save dialog.  When doing so, the entire device becomes unresponsive for extended periods of time, even making killing Locus tricky.  And even after that has been achieved successfully, Locus will immediately restart, continuing to record the track and stall the device.  This does not happen when doing the same via Locus's internal track recording bar.

This is with current Locus Pro on a Samsung Galaxy S II with ICS (Android 4.0.3), custom ROM and kernel.


Marco

Wow, that was fast. Thanks heaps!

Hello,

Hunting for a confluence today, I noticed that Locus may display minute values of 0.000 as 60.000 (certainly due to rounding or some floating-point peculiarities similar to the existence of both positive and negative values of 0) — I'm attaching screenshots evidencing this.  Would it be possible to apply some logic specifically correcting 60' to 0, at least on the GPS screen'?  Of course it's not a matter of any importance, but obtaining proof of visiting confluences is made 75% harder this way.  

Seems to be fixed now, thanks again!

OK, I'll check it once it's out.  Thanks!

I've observed multiple times that Locus Pro names NMEA logs it creates after the date of the day before (I'm in MET).  In fact, it always does this for me -- can anyone else confirm this?