Application no longer starts after update to 5.5.3Donate
2 posters
Application no longer starts after update to 5.5.3Donate
When starting the Application, the Banner starts and never stops.
- the balcon on the bottom goes to about 10% and stops.
Everything was working fine before the update on the 5th of August.
Since there is no log (that I could find) it is hard to explain anything more.
Is it possible to recieve a apk file in case something like this happens?
Mark Johnson
- the balcon on the bottom goes to about 10% and stops.
Everything was working fine before the update on the 5th of August.
Since there is no log (that I could find) it is hard to explain anything more.
Is it possible to recieve a apk file in case something like this happens?
Mark Johnson
mj10777- Cantidad de envíos : 4
Fecha de inscripción : 2013-06-22
Re: Application no longer starts after update to 5.5.3Donate
Hi;mj10777 wrote:When starting the Application, the Banner starts and never stops.
- the balcon on the bottom goes to about 10% and stops.
Everything was working fine before the update on the 5th of August.
Since there is no log (that I could find) it is hard to explain anything more.
Is it possible to recieve a apk file in case something like this happens?
Mark Johnson
try uninstalling/installing again,
orux
orux- Cantidad de envíos : 3946
Fecha de inscripción : 2009-07-06
possible cause for application not starting
This seems to be caused by using big mbtiles files.
As suggested I reinstalled (without being asked to redonate).
After reinstallment the same error accured.
I deinstalled again and after renaming the original directory reinstalled.
The Application started with the default values.
I then added a directory with only 2 mbtiles that I knew worked before (1,5 MB and 244 MB in size)
- leaving out the new big mbtiles file (776,5 MB)
The application started.
I refreshed the database.
This took much longer than in older versions.
After this was finished I selected a mbtiles file - the Application crashed.
After restarting the mbtiles file showed properly.
I then stopped the Application and moved the big mbtiles file back into the directory.
Restarted and refreshed - which went on for a very long time.
At this point I am afraid I was distracted and when I looked again at the Tablet, the Application was gone.
Restaring it again, the banner,again, never ended.
I killed the Application and removed the big mbtiles file.
Restarted and refreshed and selected a smaller mbtiles file.
It showed properly. When closing the Application it crashed - but this time it offered to send a report.
- SQLiteDatabase.jave : closeDatabase ; Linenumber 1277
Restarted the Application: after 2-3 minutes of the banner - the the map was shown.
Restarted the Application 2-3 times after that: the map showed after a few seconds.
As for the mbtiles files themselfs, I believe them to be correct.
They are from georectified images I created last Winter of the '1861,The royal atlas of modern geography,Alexander Keith Johnston' Atlas.
- the first : Zoom 0-3 of the World Map
- the second as a copy of the first, with Zoom-levels 4-7 of the Continetal maps
- the third, a copy of the second, with Zoom-level 8 of the Countries Maps
so they are all of the same structure - so if one works, all of them should work.
gdalinfo shows a correct result for each.
So I don't think this is the problem.
What I have noticed, is that it now takes longer when the Map-Database is being built.
But basicly for mbtiles all that is needed is to read the 'metadata' table.
Therefore for read-only access, the size of the database itsself should not be relevent.
BTW: why is a (empty) 'android_metadata' table needed for OruxMaps to read it?
- this is not part of the mbtiles specification and should not be needed
In the long term I would hope that the default db-type of Oruxmaps would use the mbtiles-specification
At the moment, your created db's are not self contained.
An extra .xml must be read so that the CalibrationPoint is known, since the tile numbering always start at 0,0.
Since the db itself always have the same name - a extra directory is needed.
Because of this, new tiles can never be added that are North/West of the CalibrationPoint.
Also the problem that the same image could be stored multible times would be avoided.
The fact that gdal supports the mbtiles specification is in itsself a good reason to use mbtiles as the default db-type.
Mark Johnson
As suggested I reinstalled (without being asked to redonate).
After reinstallment the same error accured.
I deinstalled again and after renaming the original directory reinstalled.
The Application started with the default values.
I then added a directory with only 2 mbtiles that I knew worked before (1,5 MB and 244 MB in size)
- leaving out the new big mbtiles file (776,5 MB)
The application started.
I refreshed the database.
This took much longer than in older versions.
After this was finished I selected a mbtiles file - the Application crashed.
After restarting the mbtiles file showed properly.
I then stopped the Application and moved the big mbtiles file back into the directory.
Restarted and refreshed - which went on for a very long time.
At this point I am afraid I was distracted and when I looked again at the Tablet, the Application was gone.
Restaring it again, the banner,again, never ended.
I killed the Application and removed the big mbtiles file.
Restarted and refreshed and selected a smaller mbtiles file.
It showed properly. When closing the Application it crashed - but this time it offered to send a report.
- SQLiteDatabase.jave : closeDatabase ; Linenumber 1277
Restarted the Application: after 2-3 minutes of the banner - the the map was shown.
Restarted the Application 2-3 times after that: the map showed after a few seconds.
As for the mbtiles files themselfs, I believe them to be correct.
They are from georectified images I created last Winter of the '1861,The royal atlas of modern geography,Alexander Keith Johnston' Atlas.
- the first : Zoom 0-3 of the World Map
- the second as a copy of the first, with Zoom-levels 4-7 of the Continetal maps
- the third, a copy of the second, with Zoom-level 8 of the Countries Maps
so they are all of the same structure - so if one works, all of them should work.
gdalinfo shows a correct result for each.
So I don't think this is the problem.
What I have noticed, is that it now takes longer when the Map-Database is being built.
But basicly for mbtiles all that is needed is to read the 'metadata' table.
Therefore for read-only access, the size of the database itsself should not be relevent.
BTW: why is a (empty) 'android_metadata' table needed for OruxMaps to read it?
- this is not part of the mbtiles specification and should not be needed
In the long term I would hope that the default db-type of Oruxmaps would use the mbtiles-specification
At the moment, your created db's are not self contained.
An extra .xml must be read so that the CalibrationPoint is known, since the tile numbering always start at 0,0.
Since the db itself always have the same name - a extra directory is needed.
Because of this, new tiles can never be added that are North/West of the CalibrationPoint.
Also the problem that the same image could be stored multible times would be avoided.
The fact that gdal supports the mbtiles specification is in itsself a good reason to use mbtiles as the default db-type.
Mark Johnson
Last edited by mj10777 on Mon Aug 12, 2013 6:47 am; edited 1 time in total (Reason for editing : small corrections)
mj10777- Cantidad de envíos : 4
Fecha de inscripción : 2013-06-22
Similar topics
» Opencyclemaps no longer working in oruxmaps?
» Download Map Tiles for North American Mountain Ranges
» add empty map no longer working
» GPS altitude offset is no longer available
» Beta V3.5.8 Max speed broken
» Download Map Tiles for North American Mountain Ranges
» add empty map no longer working
» GPS altitude offset is no longer available
» Beta V3.5.8 Max speed broken
Permissions in this forum:
You cannot reply to topics in this forum