Messages

[[SOLVED]]

I used to have subfolders in Locus/mapItems on my previous phone, running Android 11. Locus Maps handled these without problems.

Then I got a new phone, a Google Pixel 6, running Android 12. Knowing about the new rules, I copied the content of Locus/mapItems into Android/data/menion.android.locus/files/Locus/mapItems .

Locus Maps could use items in this internal mapItems folder, and it saw and showed the subfolders as well. But when trying to enter any subfolder to make items in it visible, none were there. I could still see all the item files in a file manager (I use X-plore), so the files were actually there, but Locus Maps apparently did not see or show them.

Then I received the update to Android 13. Since then X-plore also no longer sees anything inside Android/data/ , so I am now unable to even delete them.

I have since uninstalled Locus Maps entirely to clean up the mess. I could import most of the data (tedious work), but I still have no way to have subfolders in mapItems. Without subfolders, mapItems are difficult to handle when there are many.

What's the current situation with Android 13? How about allowing to change mapItems to an external folder, like Locus/mapItems, akin to some other folders that can be moved to an openly visible place?

[SOLVED]

Only some days after writing the above I learned that there is still one simple way to read and write in Android/data, an MTP connection to a computer. I connected my new phone via USB to a PC running Windows 11, allowed data moving, and could easily copy folders into Android/data/menion.android.locus/files/Locus/mapItems , using the computer's keyboard and mouse.

Locus Maps then handled these folders and their content, GPX files, just as easily as on my previous phone, so no problem any more.

Why it didn't work in the beginning, when the subfolders should already have been in place, remains a mystery. Anyway, as long as MTP does the trick, I'm happy.

[Edit: Found the cause, problem mostly solved. See below.]

I got a new phone, a Pixel 6, still running Android 12. On that I get these errors when a freshly recorded track is auto-exported.

• setTitleColor, code: 0
• Error: UsbInterface, code: 12561

I can then manually export the track without any problem, which is my current workaround.

But perhaps somebody wants to look into this. Is there anything I can do to help pinpoint the defect?

Everything else seems to work fine, except that I have lost all maps over the phone change. Not too bad, I can re-download them. Thanks for the good work! I like Locus Maps.

Hans

Edit: Apparently I found the cause. There are two different places where the auto-export path can be entered. They differed in my new installation. The location in the settings was still sdcard/Locus/export, while in the manual export I had already entered storage/emulated/0/Locus/export. Therefore the latter worked with manual export, while the auto-export attempted to use the old path. I did not get the idea that the path setting exists in two different places.

After changing to the new path, auto-export worked fine in the first test.

This solves the problem for me, but I think, Locus Maps should still be changed to show a more meaningful error message when the export path does not exist. Also I would recommend to avoid the two different path settings. I think, auto-export should always use the same path that is set for export. I think, to have a different setting for manual and auto export is practically never needed, but has a high potential for confusion.

How about using a battery pack to prolong the battery life of your device? They are available in all shapes and sizes.

I have one. I do that already. It is a bit awkward though and makes it more difficult to put the phone in the best place in a cramped airliner, sometimes behind the window shade. Clever software can perhaps achieve the same thing without extra hardware.

I often need the power pack to recharge the phone while changing planes.

If you want to save battery whilst recording a track I am not sure how efficient it would be to just record one point every few minutes. From my understanding the GPS of your device would have to be switched off between recording your trackpoints in order to save battery. When you want to record your next point the GPS of your device has to be switched on again and has to get a fix on the satellites again, before being able to record your next point. Being in an airliner you would have covered quite a distance in the meantime, which would increase the time to get the next GPS fix.
If, on the other hand, your device´s GPS stays on all the time and only records a point every few minutes, I don´t see how this would reduce the battery drain..?

It is a tradeoff and the time between trackpoints where switching off the GPS saves energy is different for every phone type. When I once experimented with this (a long time ago with an older smartphone), I found that taking one track point every 2 min and having the GPS off in between saves quite a bit of battery charge. Consider that probably the entire phone goes to sleep in between track points, if the app is programmed cleverly.

You have to consider also that modern GPS chips are blindingly fast in acquiring a fix. My new phone often gets a fix within 4 s, even indoors (with a window). Often, but perhaps not always, I can put it on the table in front of a window seat in an airliner and still keep tracking, something which I could only very rarely do with older smartphones, which needed to be kept right at the window.

Thanks for your reply! Your proposal sounds like a very good solution.

You wrote, "But I guess this is very specialized use case ..." I think the automatic adjustment you describe is the general use case that almost everybody wants. Most users who track want to know where they were, not how many track points per kilometer they want to record.

After reading your message I found and looked at the GPS auto-off and related settings. I had tried these a long time ago, but had then forgotten about them.

I cannot use them anyway. They are far too weird for me to understand. Must be about a dozen settings that could all influence each other, and how they influence each other is completely unclear.

Just one example: "Min accuracy". Ostensibly it influences when the GPS is kept on. It is measured in meters, which means that more meters correspond to less accuracy. This already raises the question whether "Min" means minimal accuracy or a minimal meter figure. Apart from that it is completely unclear whether this setting overrides the other auto-off-related settings or whether it is overridden by other, conflicting settings.

Another example, out of many, is the interdependence of the GPS auto-off settings with the track recording profile. If the time interval given in the tracking profile is smaller than that in the GPS auto-off settings, will the GPS then stay on or not? Again, which setting overrides which other setting?

And on and on in this fashion. I don't have a week of free time to study all related settings and test how they interact with each other.

Unfortunately it also makes little sense to ask here about all of these settings, because I would have severe doubts whether the person answering actually knows the right answers or just guesses. I could not believe anybody anyway, except perhaps the programmer who wrote Locus, and even he might not know all these interdependencies off-hand.

I am a computer programmer. If I shy away from these settings, then 99% of non-technical users will have no clue what they mean when combined. The design aims for a user who may not exist.

If I could give a hint at how Locus could be improved, then I would say, remove most settings and make them automatic. Or leave them there for the 1% of users who manage to understand them and put an "automatic" checkbox above them.

For example, for tracking I think only two settings are needed:

1. Time between automatic checks for movement after the phone has been found not to move much for a while. Default: 10 min

2. Average accuracy of interpolated track. This could be given as an absolute distance tolerance like 10 m plus a time tolerance like 10 s, so the total distance tolerance grows with speed. Since this concept is a bit difficult to grasp for non-mathematical thinkers, it would probably be better to give the user three simple choices like fine, normal, and coarse, and in the help file list the distance accuracies and a hint about which speed would lead to battery savings due to the GPS being switched off between track points. List these for a few commonly occuring speeds. I would even dare to say that almost all users would be fairly happy with just one fully automatic setting, i.e. no setting at all, with automatic adjustments as described in the preceding posting.

I would not ask for average accuracy in m, because in all use cases I can think of, the distance tolerance grows with speed.

This would also nicely make tracking profiles superfluous, because instead of changing the tracking profile it would be just as easy to set the accuracy to coarse before I board an airliner (if that were even necessary, because at high speed the distance tolerance would grow anyway). And it would make the GPS auto-off settings superfluous, because Locus could easily decide for itself when to switch off the GPS between track points. Locus could measure the times the GPS takes to find a fix after being powered up, to adapt the decision to the individual phone.

Generally my recommendation would be to think harder about what most users really want, instead of what an engineer might perhaps want.

That said, I want to stress that I like Locus very much and believe it is by far the best offline mapping app, with Google Maps being the only serious competitor. I use both. There is just always room for improvement.

What is the best way to record a track while riding in an airliner?

The main problem is power consumption if the GPS is kept active all the time. Since airliners fly absolutely straight at constant altitude and with mostly constant speed, there is harly any need to have more track points than one every two minutes. Perhaps even one every five minutes would suffice.

I think the nicest solution would be to have an automatic adjustment of the track point frequency, depending on the regularity or irregularity of the movement, but I think Locus currently does not have this.

Perhaps it could be a possible improvement to add something like automatic low-power tracking. My personal wish would be that the phone checked its movement, using as little power as possible. When it detects movement, it could then adjust its track point frequency accordingly. For example, if I keep moving in a straight line at constant speed, the track point frequency could be very low.

Thanks for your quick reply!

No, I did not mean blank areas inside a vector map. I was referring to adjacent maps, but your hint of the auto-load setting solved this problem. Thanks for this!

Actually I am wondering why that setting is even needed. Why not have it always on? Who in the world wants to stare at a completely white map?

As to the maps with different "resolutions", the problem maps indeed did not come from the Locus Store. I will probably restrict myself to the Locus Store to avoid this problem. How about payment by bitcoin? 

I have downloaded a few vector maps, but I seem to have some fundamental problems. The biggest one is that I see a white screen instead of the map. It seems that I can only see one map at a time, which is particularly irritating when I look at the border area between two maps or when I zoom out far enough to have two or more maps on one screen.

With other maps the Locus strategy has always been that the map tiles appear when I move the map to another place. Is there any good reason to deviate from the original strategy? It has always seemed OK to me.

More generally I would wish that Locus always shows me a map if I have one for the area I am looking at. What sense does it make to show me a white area? Even when I have vector maps and move to an area for which I have only a raster map, what is better, if I see the raster image or if I see nothing?

Yet another problem was that I had a vector map of Germany and a much more detailed vector map of Bavaria in Germany. Of course, when I look at a place in Bavaria it does not make much sense to show me the much less detailed Germany map. I think, Locus should automatically change to the more detailed map if the user has overlapping maps of different detail and zooms in as far as to actually show the details.

... do not return correct path with trailing "/" in the end. So in case of Track record, Locus on some devices create a path as sdcard/Locuscache/track_rec ... which cause troubles.

On my phone (OnePlus One) track recording worked correctly several times, then one morning it failed.

So if the missing slash is the cause, that would mean that the slash is usually there, but is occasionally missing. This sounds a bit strange.

But there could be more than one cause.

I have run opera music runkeeper weatherpro etc. together. Google nav actually not. I don't know how much it consumed, just saying that I can't remember something like this.

The crash happens only when other apps use more than the remaining free RAM, because then Locus can get kicked out to free some RAM. The Locus track recorder service keeps running though, so you still see the track recording notification.

I guess you can see in Settings, Apps, RUNNING, whether Locus is still running or whether only the track recorder service is running, but I am not sure—never tried. I should have looked at that.

When you then start Locus, it always crashes once. Start it a second time, and it runs just fine.

Hmm I'm lucky to not have experienced crashes while recording (two years of use on Xperia P with 1 GB RAM ics, jb, cm10.1)

Have you ever run two or more additional apps, at least one of them as RAM-guzzling as Google Navigation, while running Locus for track recording? I suppose yes, because otherwise your message would not make any sense. One possible explanation is that CM 10 uses less RAM than CM 11.

Thanks again for replying! I have killed Locus. Could not do anything else anyway. But first I made a copy of the entire Locus folder.

Currently recorded track is, before save into database, store in Locus/cache/trackRec directory.

That directory was empty before and after killing Locus.

Anyway what I suggest

- create a log by this method http://docs.locusmap.eu/doku.php?id=manual:faq:how_to_create_debug_log - there may be any clue why this happen

The "Take bug report" command was greyed out. Could not do it.

- backup of whole Locus folder if possible

Done.

- terminating Locus and open again. Locus should offer "unsaved track record" so try it again

Unfortunately it did not offer that. The track completely disappeared. All older tracks are still there though.

My life does not depend on that track, but I would feel better if I knew a way to keep a track even if there is some failure.

Have you ever considered to regularly export the track that is currently being recorded, like every couple of minutes, overwriting the previous export of the same track? Locus could do that if the automatic track export is enabled. I think the time between such automated backups should be initially short, like 2 or 4 minutes and could get longer as the track becomes longer, like 10 or 15 minutes after moving for more than an hour.

But if the track recording function always worked reliably, there would be no need for such automatic backups while recording.

- if non of this work, I also suggest check your SD card on PC

No SD card on this phone (OnePlus One), just internal memory.

- optinaly you may try restore database over Backup Manager

Good idea, but I was only worrying about that one last track, which was not yet in any backup.

I hope you can find a way to prevent this kind of failure. Unfortunately I could not find out the cause. I did not do much on the phone while recording the track. Two other apps were running (Maps/Navigation and another small one), but I think they should not interfere with Locus. The error occurred when I tried to stop the recording.

By the way, while I'm at it, let me mention another problem that I regularly had on my previous phone, a Galaxy Nexus, also running CyanogenMod 11. That phone had only 1 GB RAM, which was not enough. Apparently, while Locus was recording a track in the background, the main Locus program often got kicked out of RAM due to the regular RAM shortage, while the recording service kept running just fine and kept recording.

When I then recalled Locus via the notification or in any other way, it instantly crashed, and I often sent in the crash report. After this crash, on the second attempt, Locus always started properly and allowed me to stop the tracking and to save the track. Never had any problem the second time, except that Locus always reverted to a no-map display, and I had to reselect the desired map type.

The old phone is now retired, and due to the 3 GB RAM I now have, I hope to never see that crash again. But you may still want to look into it. It is easy to reproduce on a phone with 1 GB RAM by loading a couple of apps that want to run in the background, like Google Navigation and a few others.

Thanks for your quick replies!

In Locus/data/database there are two database files, tracks.db and waypoints.db, and the corresponding *.db-journal files.

I am still trying to save the track that is currently recorded (paused). I do not want to kill Locus because I fear that that would kill the current track.

Any ideas what I could try? Should I delete the databases? Everything except the current track is already exported and saved.

But what do you think about this post from the discussion you mentioned above?

----- Quote begins -----
#105 fatih.fd...@gmail.com

I have written a small app. The files created by my app is not visible on PC. But if I use this code " sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, Uri.fromFile(file)));" foreach file. The files are visible. I think there is no bug. The problem is developers who not use fully the Android enviroment.

I have tries a couple File Explorer, and ES File Explorer is working good. The changes it cause is immediately applied to PC.
Stock apps (camera,contacts) are also working well. New photos, deleted photos, the export file of contacts is immediatly applied to PC.

So the problem is not Android. The problem is developers who not uses the Android enviroment properly.


Android developers may add this process to the .createNewFile, .delete, etc. methods. But maybe there is something which we don't know why theye don't add.

Thus, if an app which creates (copies) , moves (renames), and deletes files-directories, has this problem, tell it to the developer of the app. They should use some code like a sent above.
----- Quote ends -----

This has been reported before at least once, in 2011. I cannot save the track I just recorded and get the error message, "Unknown problem with track saving!"

Locus/data contains a number of folders, 5 files whose names begin with a period, and these two files:

• databasefavorites.sqll-journal
• dbtracks.sqll-journal

There are no *.sqll files in Locus/data. I have deleted the two .sqll-journal files, but still get the same error.

I normally have automatic export switched on, but switching it off does not help. My impression is that Locus is unable to write to a database.

I cannot exit Locus, unless I delete the current track, which I do not want to do. I will keep trying workarounds and hope for a good idea before Android kills the still running Locus.

When the phone is connected to a computer via USB, using MTP, the exported files are not visible before the phone is rebooted. Solution from

https://code.google.com/p/android/issues/detail?id=38282

When writing files that should be accessible via USB MTP by the user:

For each file:

sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, Uri.fromFile(file)));

Otherwise the files remain invisible.

Current workarounds are to reboot the phone or to rename the export folder using ES File Manager and, if that is not enough, disconnecting and reconnecting the phone. There may be other workarounds.