Messages

Hello, I have just done several tests with the beta5 version.
Login on strava : ok

Hi, Thanks for trying this. I've done some more testing and I've managed to get it to work. I think the issue was that I hadn't reconnected with Strava since installing the new beta and somehow it was using the Strava authorisation from my old v7.4.23, the permissions it askes for are different which might explain why it didn't set the activity type properly, unfortunately I can't replicate the issue, but it's not such a big problem.

The other issue I had about not being able to authorise with Strava is real, it just depends how I try to authorise. If I go to Global Settings -> Integration -> Strava -> Login then it works as expected. If I revoke the authorisation and go to Tracks -> Properties -> Upload to -> Strava -> Connect with Strava then I get to the Strava login page, but when I press "Authorize" it just goes back to the upload GPX window. If I press "Upload GPX" then it just shows the Strava authorisation page again, but it doesn't matter how many times I press it, it never connects.

Hello check the integration settings, strava, there are you can configure what type of activity is the one that is uploaded by default
Also tell you that in strava it takes a while to show the type of activity received from OruxMaps, if you look just when the activity from OruxMaps has been uploaded to strava it is very possible that it always puts training, but after a few minutes for example 10, this is already updated and puts the correct activity, this has been happening for a long time,  I have checked it out
Best regards
🅃🅁🄾🄽🄿🄾

Thanks for the help, but I don't think this is the issue. After more than half an hour the activity type is still "workout". The default activity in my Strava settings is set to "cycling" which is what I'm trying to upload.

In any case, I've just tried uploading an activity using an old version of Oruxmaps (v7.4.23) and the activity type is immediately set correctly, so it looks like it's a regression in recent versions of Oruxmaps.

Also, I tried revoking Oruxmap's permissions to access Strava from the Strava settings so I could re-link Orux to Strava to see if that made a difference. However it wouldn't even re-link. I successfully authenticated with Strava and was able to press the "Authorize" button to link my Strava account, there was no error message but Oruxmaps doesn't show as an app in my Strava settings and uploads from Oruxmaps fail. It seems that Strava integration is broken in this version.

Hi,

The new beta seems to work great and I have no problems with the files being stored in the media folder.

However I have a small problem with uploading tracks to Strava which I also noticed on the previous beta I was using (10.7) - it doesn't matter what track type I select when uploading, in Strava it always appears as a "workout" instead of e.g. ride or run.

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.