Messages

Hello Marty,

I was looking at this problem and still not able to find a reason for this. Anyway, version 4.33.0 was just published and some changes are inside regarding this problem. So, give it a try. If the problem persists and you will be willing to test a special version, let me know. I'll have to prepare a version that will print some more information into the log file, for analysis. Thanks.

Will try it once it is in G. Play

So basically no change even though I deleted the file. Weird.

^ I was able to locate the file thru Files app (which I suppose have some extra access rights, I was prepared to use adb and shizuku).
1)It was 4MB large, so I deleted it.
2)after opening the app again and checking the database folder again, I see the file again, but woth 41.37kB.
3)Then I locate a random multi cache, hide 5 of its waypoints, close the app
4)The file now has 41.32kB
5)I open the app, waypoints are visible again and the file is 41.37kB

Yes, the file path is My Library/Points/geo waypointy.

It does this when I exit with one time hitting back button and then hitting the EXIT button. I've just tried if it does this if I kill the app in "task manager" and start the app. Same behavior.

EDIT: So the standard method of back+exit. When starting the app again, it loads the waypoints even before the vector OAM map (which loads a second later).

EDIT2: I've tried to delete the geocache and add it again by its GC code, hide the waypoints. Then exit via back+exit => same behavior.

New discovery. When I
1)manually hide waypoints for a cache
2)close the app (or the app is killed by memory manager, or by restarting the device
3)open the app again
4)the waypoints load again

This is unwelcome, as there is then no point in hiding them, when it don't last.

When I add a new geocaches, I want waypoints selected in menu loaded. But when I have a geocache already added (in a folder somewhere) with its waypoints hidden (or just some wayp. hidden, some visible, certain caches takes many days/weeks to find all distant waypoints, so by hiding some, you see where you already were and where you weren't), it loads all waypoints again.

This is problematic, because when travelling to a location, it is wise to update the geocaches, so you see if some are now disabled, or new logs on them to help you. But by updating my folder with them, it loads all the waypoints again, including those I manually made invisible (making useless me hiding them in the first place). And the searching for new caches in the area (overwriting old, but not remembering the old had waypoints hidden).

My stop-gap workaround isn't elegant, I add such cache to special folder (I named it Waypoints), then go to geocaching.com page for the cache and ignore it. This way, it isn't again when searching for new caches (because it is ignored, but is in Locus app point folder). I cannot update it though without it loading all waypoints again.


Center of Prague especially looks like Star Wars movie - laser shootout. Some geocaches have waypoints tens/hundreds of km's wide.

Here is longer track showing various icons. Sometimes I welcome this feature, sometimes it is just visual clutter which cannot be removed from the screen.

Is there, or can there be an option to turn on/off railroad crossing icons, when planning a track? It shows on saved track as well.

I'd like to ask if anyone experienced these "spikes" - I was standing still and suddenly I saw myself on display going away.
Recently I've tried to change gps.conf file in Android settings to fix another bug. Maybe it's related.

So does this seem familiar to someone?

Not sure if discussed before, but can you have % representation of favorite points? For example in points folder, having not just (Heart icon) 39, but behind it also %25 of all premium logs.

Bump, it would be a really nice feature to have.

Had to downgrade again, because though my offline saved maps worked, online (custom) maps from mapy.cz didn't. Their tourist maps are the best maps in my opinion, so having those is the most important for me.
I've tried to fox it by editing custom.xml file, but even after 2 hours, no succes. So I downgraded.

Quite interesting.
We play to publish new Locus Map version in the middle of May, so if possible, give it a try (you may simply try a Free version as it shares same code) and let me know, thanks.

Updated now. For now, it works. Will have to try it for longer time.
The only problem for now was 3-minute long starting time. Then I exited the app and 2nd start time was back to good times of 30s, as in previous updates. 

Good day MartyMcFly89
thanks for bug reports. These crashes in app native code are almost unsolvable to me, sorry.
What I may suggest is to try to disable acceleration of map if it helps.
For this, activate expert settings and disable "Map hardware acceleration" settings. Hope this helps.
Or if you want, it is possible to downgrade to the older version of Locus Map, if you think it does not had these troubles before.

Downgraded to 3.35.2 and it works just fine.

Again crash:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'xiaomi/mido/mido:7.0/NRD90M/V10.2.3.0.NCFMIXM:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 11636, tid: 11747, name: RenderThread  >>> menion.android.locus.pro <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'GL errors! frameworks/base/libs/hwui/renderthread/CanvasContext.cpp:517'
    r0 00000000  r1 00002de3  r2 00000006  r3 00000008
    r4 bca5f978  r5 00000006  r6 bca5f920  r7 0000010c
    r8 a4797800  r9 00000000  sl be094244  fp be094240
    ip 0000000c  sp bca5ef38  lr e801b2c7  pc e801db48  cpsr 200f0010

backtrace:
    #00 pc 00049b48  /system/lib/libc.so (tgkill+12)
    #01 pc 000472c3  /system/lib/libc.so (pthread_kill+34)
    #02 pc 0001d565  /system/lib/libc.so (raise+10)
    #03 pc 000190b1  /system/lib/libc.so (__libc_android_abort+34)
    #04 pc 00017114  /system/lib/libc.so (abort+4)
    #05 pc 0000c539  /system/lib/libcutils.so (__android_log_assert+112)
    #06 pc 000239d7  /system/lib/libhwui.so
    #07 pc 000252df  /system/lib/libhwui.so
    #08 pc 0002874b  /system/lib/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+122)
    #09 pc 0000e575  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+140)
    #10 pc 0006c0d1  /system/lib/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+80)
    #11 pc 00046d93  /system/lib/libc.so (_ZL15__pthread_startPv+22)
    #12 pc 00019afd  /system/lib/libc.so (__start_thread+6)

When resuming route planning, the app crashes. Not always, but very often. Latest store version of Locus. I don't think it did this before.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'xiaomi/mido/mido:7.0/NRD90M/V10.2.3.0.NCFMIXM:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 4865, tid: 5135, name: RenderThread  >>> menion.android.locus.pro <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'GL errors! frameworks/base/libs/hwui/renderthread/CanvasContext.cpp:517'
    r0 00000000  r1 0000140f  r2 00000006  r3 00000008
    r4 bcc7f978  r5 00000006  r6 bcc7f920  r7 0000010c
    r8 bbd2a800  r9 00000000  sl bd2e44a4  fp bd2e44a0
    ip 0000000c  sp bcc7ef38  lr e801b2c7  pc e801db48  cpsr 200f0010

backtrace:
    #00 pc 00049b48  /system/lib/libc.so (tgkill+12)
    #01 pc 000472c3  /system/lib/libc.so (pthread_kill+34)
    #02 pc 0001d565  /system/lib/libc.so (raise+10)
    #03 pc 000190b1  /system/lib/libc.so (__libc_android_abort+34)
    #04 pc 00017114  /system/lib/libc.so (abort+4)
    #05 pc 0000c539  /system/lib/libcutils.so (__android_log_assert+112)
    #06 pc 000239d7  /system/lib/libhwui.so
    #07 pc 000252df  /system/lib/libhwui.so
    #08 pc 0002874b  /system/lib/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+122)
    #09 pc 0000e575  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+140)
    #10 pc 0006c0d1  /system/lib/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+80)
    #11 pc 00046d93  /system/lib/libc.so (_ZL15__pthread_startPv+22)
    #12 pc 00019afd  /system/lib/libc.so (__start_thread+6)