Messages

On a slower tab handling huge maps with the overlay feature, I found that even in a 100% setting the base map is rendered, then overlay on top.

@Menion: we discussed that years ago - why is that? 0/100 are special cases that can be identified trivially ...

0% is obviously a simple case... 100% not so much. At least Locus would have to check if the overlay map data comes with an alpha channel. I use a 100% strava heatmap overlay quite often and obviously, the basemap still has to be rendered.

Switching between two maps is simple. Just use the function "Overlay Map" with cover 100%. This can be turned on either a separate button or in the "Map screen" "click" Eye ".

I suppose that would be twice as slow and eat twice as much battery for rendering. Or does the overlay handling have special optimizing for funky 0% and 100% use case?

Anyway, I use the overlay for different things (strava heatmap), so it wouldn't help my case. Locus still struggles big time with caching from the heatmap tile server btw, but that's a totally different story :-).

Long tapping the map icon (the two stacked rectangles bottom left) is unused so far and simply does nothing. Toggling between the last two maps seems like a reasonable action.

Switching between maps is something I do very frequently on the trail, most of the time toggling between OSM and a satellite map. I believe this is a very frequent operation in Locus, especially now that you have these gorgeous satellite maps in Gold without google hacks. Anyway, map changing has become a bit of a cumbersome multi-tap operation recently: tap on the map icon, tap on the current map name (feels a bit illogical here), find new map in the list, tap on new map name. One could probably put the quick map change function in a toolbar, but that doesn't make the tap orgy less complex really.

How about using a long tap on the map icon (currently unused) to toggle between the previously selected map and the current one? That would make things super-easy and fast if all you need is two maps, like OSM and Satellite.

Rebooting the phone fixed it, no idea what was broken. Please ignore me. Speed is back to normal.

Did something change with point rendering lately? I just updated to 4.7.1 and the zooming performance went from buttery smooth to a horrible 2 fps with about 6000 enabled points, no tracks.

Points didn't seem to affect zooming speed at all before... now it's close to unusable.

Test file with 7000 blog entry Points:
https://alpenzorro.com/alpenzorro-allpoints.zip

Performance is dead no matter if any of these points are actually visible or not, ie zooming is at 2 fps even in completely different parts of the planet. If I remember correctly, Locus had the same problem years ago. Then there were some very efficient fixes that made everything super smooth. Now the problem is back.

Or was I just dreaming? Can do more testing if you could link to the APK before 4.7.1.

Edit: rebooting the phone fixed it, locus Multipoint FPS is back to normal.

Why is the "export" directory important? Does it make difference if exported data are in the internal or external private directory? I'll look at it later. I believe that "export" should be improved in a similar way like "backup" works > so directly into the root of int/ext storage. It will just need a little more work ...

During a trip, I always export tracks directly to the folder that also contains the trips photos. This folder is then synced to my server. Not being able to pick an arbitrary folder on my file system as export directory in Locus is a bit of a nuisance... but I guess Android 11 restrictions just happen :/

Just to confirm... all my Locus disappearing while silently recording tracks in the pocket happen on Samsung Galaxy S20 FE-5G with default OS, all Samsung Updates installed, no root, no clever hacks running, trying very hard to disable all battery saving and other Samsung bullshit in Settings. No luck so far, I still have multiple Locus disappearings per day and cannot properly record a single track without paying constant attention to my phone.

I once saw a Locus warning about battery saving options, but never again.

Also, I sometimes have a feeling that Locus goes away more likely whenever I am having a picknick break, like not moving for a while. Might just be superstition though. Sorry for being otherwise clueless.

Your notifications are really weird... restored somehow by the system long after Locus was quit... hanging around forever and being dead to tapping. I know you blame Samsung... but many people use Samsung... so maybe try to work around it before release to prevent complaints? It's really strange... can't remember Locus Pro doing this, but that was many OS updates ago.

This is not beta related, it's a android 11 / samsung horror issue I presume.

As for the cronjob, there is this Tasker plugin for Locus, it allows to check Locus states, eg if it is recording. ie it offers variables to Tasker. Unfortunately it does not seem to work with L4, maybe you may reach out to the dev Falco.
EDIT: It works! I made a successful check on %is_track_rec_recording
https://play.google.com/store/apps/details?id=falcosc.locus.addon.tasker

I was also doing alive checks for a while with a beep every 5 minutes, because my prior device crashed and rebooted quite often and unnoticed by me.

I am using live tracking with audio beeps for that purpose. No more beeps... Locus is dead. Still miss that from time 2 time and lose my track recording. It's just a nuisance while biking obviously... but can lead to a bad situation easily with more "serious" activities. Backtracking on a glacier in a whiteout without a properly recorded track can become surprisingly deadly.

Locus was always rock solid until Android 10 on Samsung Galaxys, now on 11 it's hit and miss. It's likely not menions fault, but still his problem :-).

Thanks for that Tasker thingy, will give it a try later.

[@joeloc]

@joeloc
As I see, for time downloading there is already set a 5 minutes timeout! I believe this is really long enough. What about contacting the guy behind this solution?

Apparently it's not long enough, otherwise it would work, wouldn't it? After all, the map sort of works as an online map... minus your tile rendering from cache bug that you keep denying :-). How often do you retry to grab a tile when a request times out?

How about a button "retry forever until manual abort" on the 1st error then?

Point overwrite crash is fixed. Locus still dies randomly once or twice a day while phone is pocketed away, just recording a track. Obviously, nothing will be recorded until you notice Locus has disappeared.

Apps can no longer hold wake lock in foreground services:
https://issuetracker.google.com/issues/179644471

https://dontkillmyapp.com/samsung

has up-to-date info on samsung killing apps. Maybe it helps to find a workaround? I know you own a Pixel, but likely the majority of your users have Samsung. They will suffer the same fate as I. I am considering running a cronjob to restart Locus every 5 minutes to avoid losing too much of my track.

This is not beta related, it's a android 11 / samsung horror issue I presume.

[@joeloc]

@joeloc

Heat map > sorry, but it works quite slow and when I spend a little more time on this, I do not see any clear problem. Because it is not an official app map and because no other (official) map does not have any similar issues, I won't spend time on this.

Understood. Would you maybe consider putting the (multiple?) max_timeout and max_failure_count variables into config.cfg then? That way we could still download from slow servers... even if runs 12 hours overnight.

Right now, slow server download is simply impossible with Locus. Nobody wants to watch his phone and click retry every 3 minutes.

Ps, Strava Heatmap might be lagging and from Russia, but it nevertheless is *the* *most* *valuable* overlay for mountainbiking today, not just some funny idea of mine :-).

See Attachments for the add point crash, happens 100% when clicking Speichern. Point "Auto" is already in the db in the same folder. Adding points with other names is no problem.

Locus crashes reproducably whenever I add a new point with a name that's already in the database... in my case it's "Auto". That's a new crash. A few versions ago, it would simply ask me if I wanted to replace/ignore/add.

Btw, I noticed nothing of the new Locus crash reporter functionality. The app just dies and goes away quietly.

The heatmap does work... I use it (with the config I posted) since at least two years as Overlay most of the time. Sometimes the russian server is slow/fails but mostly it's OK... except new Locuses tile disappearing problem obviously . Maybe new Locus cannot handle using other zoom levels to render a missing zoom level in case of a timeout? The resolution is hard to tell with a heat map anyway. I still think Locus Pro handled it more gracefully somehow.

Something is really wrong with tile rendering for this online strava heatmap. Already visible tiles disappear at random while zooming and also appear again randomly. It doesnt feel like being server related, more like locus has a problem with this specific minzoom/maxzoom values? zoompart -8 is weird too? It fails as overlay and as base map as well.

Also map download seems completely impossible, Locus always stops with the same error although the map works as online map (except the tile rendering troubles).

i believe it was fine in locus pro, but cant really remember

Code Select Expand


<provider id="8888049" type="0" visible="true" background="-1">
<name>Overlay</name>
<mode>Strava Heatmap - Ride (Bluered)</mode>
<countries>World</countries>
<usage>overlay</usage>
<url><![CDATA[https://anygis.ru/server/Tracks_Strava_Ride_Bluered_HD/{x}/{y}/{z}?locusScale={ts}]]></url>
<serverPart></serverPart>
<zoomPart>{z}-8</zoomPart>
<zoomMin>8</zoomMin>    <!-- 0 -->
<zoomMax>23</zoomMax>   <!-- 15 -->
<tileSize>256</tileSize>
<tileScale dpi="0" multi="2.0" replace="19" />
<extraHeader><![CDATA[Referer#https://www.strava.com/heatmap]]></extraHeader>
<extraHeader><![CDATA[User-Agent#Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36]]></extraHeader>
<attribution><![CDATA[Сборник карт AnyGIS. <a href="https://anygis.ru/Web/Html/Locus">Проверить обновления</a>]]></attribution>
</provider>