Messages

I'm testing 8.5.0RC5 and migrate to SD card does not work.

When I press START it seems to work and says that the migration was successful, but actually only a few of the folders have moved, the tracklogs and mapfiles folders have not been moved (and they're the big ones that I really want to move). Then it asks me if I want to delete the files on the internal storage, if I press yes it just seems to get stuck forever with a spinning icon, when I check in a file manager none of the files are being deleted. I then have to force close Orux Maps.

If I copy the files to the /oruxmaps folder on the SD card manually and change the locations of the directories in the App Storage settings page, Orux Maps just ignores these and uses the folders in the internal storage anyway. For example if I move the tracklogs folder to the SD card and change the directory to the SD card, when I go to the track manager it is blank and a new blank oruxmapstracks.db file is created in the internal storage/oruxmaps/tracklogs folder. If I move the tracklogs back from the SD card to the internal storage, my track reappear even though the setting still says it's using the SD card.

Hello,

I've discovered a bug which causes potential loss of some heart rate data when upgrading to a recent version. I'm currently using V7.4.22, I can't remember the previous version but it was probably ~6 months old.

I noticed that in older versions the HR data was stored in the "heart" table in the oruxmapstracks.db with a time index separate to the GPS data, and it kept recording for the whole duration of a track. In more recent versions HR data is stored in the trkptsen column of the trackpoints table, which means HR data is only recorded at the same time as a GPS point is recorded. I can imagine this is a cleaner way of storing HR data, but it causes 2 problems:

Firstly, when recording new tracks, if there is a gap in GPS data during a trip, then HR data isn't recorded during this gap. This is a problem with the default settings of minimum distance = 20m because if you stop moving there is no HR data, but it is very useful to see how the heart rate recovers during rests, and the average heart rate is not correct if data is missing. This can be "fixed" by setting minimum distance = 0 (always) which is what I've done, but maybe you should add a warning if a HR sensor is being used and minimum distance is not zero?

The second issue is a bigger problem though: if, in the recent version, I view a track or the statistics for a track made with an older version, it will convert the HR data from the heart table to the trkptsen column. As my older tracks didn't record GPS points when I stopped (because minimum distance wasn't zero), the HR data during these stationary periods is lost after the conversion! Hopefully I don't need to say that losing data is not a good thing!

My suggested solution is that during this conversion from the heart table to trkptsen, the app creates additional GPS points at the timestamp of the old heart data and interpolates the GPS data so it can fill in the gaps when there wasn't GPS data and allow it to use all of the HR data.

Alternatively, assuming Oruxmaps is to maintain backwards compatibility with old tracks with HR data in the heart table, does this conversion for old tracks need to happen at all?


-Tom

Hello,



I'm wondering if you've had chance to take a look at this bug? I've just installed the latest version, 7.2.14, but the problem is still there  

Yes your understanding is correct: initially everything loads correctly, and only when panning back to a region do the black tiles appear. Once a tile becomes black, the same tile is always black until I do a refresh.

Remove the file oruxmaps/mapfiles/OruxMapsCacheImages.db file.



Maybe the cache database is corrupted,

I've tried that, but almost immediately afterwards another black tile appeared. The following link is to the new OruxMapsCacheImages.db file so you can investigate what the problem might be.



http://martianmonkey.co.uk/images/OruxMapsCacheImages.db">//http://martianmonkey.co.uk/images/OruxMapsCacheImages.db



I have however looked into the file using sqlite and dumped all of the images into files to investigate. The black tile shown in the image below is at co-ordinate x=1992, y=1255 and z=12. The resulting PNG file appears to be truncated at 4096 bytes, and if I view it in an image viewer I can see just the top portion of the tile. I identified a second similar tile at co-ordinates x=1992, y=1238 and z=12, also truncated at exactly 4096 bytes. I also tried dumping tiles from my actual OruxMapsCacheImages.db file and found a number of tiles truncated at 4096 bytes. So the issue appears to be that the tiles are downloaded correctly, but for some reason only the first 4096 bytes are saved to the database file.



I hope this helps you find the problem.



http://martianmonkey.co.uk/images/Screenshot_20180312-201808.jpg">

Somehow the formatting of the original post became messed up so here is the hopefully correct link to the image showing the black squares:



http://martianmonkey.co.uk/images/Screenshot_20180226-225533.jpg">

I have a problem when viewing cached raster maps. When I view an area, all tiles of a map load and display correctly. If I scroll away then scroll back into an area, sometimes some of the tiles are displayed as black (or in 1 instance green, but mostly black). The screenshot below demonstrates what this looks like (the this is so far the only instance of a green square)



http://martianmonkey.co.uk/images/Screenshot_20180226-225533.jpg">



Note that originally the tiles load and display correctly, so the problem is not with the download or the data received, it appears to be a problem with the way the tiles are stored in the database. Once a tile is shown as black, it remains black on all subsequent views until I refresh tiles. Sometimes a tile is only partially black, i.e. there will be a flat/short black rectangle.



This is using the latest version, 7.2.7, and using a Samsung Galaxy A5. The problem appears to not be present on my old Samsung Galaxy S3, however.