search

anmpout / osmdroid

Automatically exported from code.google.com/p/osmdroid
0 stars 0 forks source link

Unexpected behaviour: Tiles removed autometically from folders in offline mode. #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
I am using osmdroid. In offline mode when i open the activity that has 
osmmap. it works fine and when i revisit this activity. It shows 
nothing. When i check the folders that has tiles from sdcard. All 
folders are now empty. It is unexpected and strange behaviour for me.  

What is the expected output? What do you see instead?
Tiles should remain until manually i remove them.

What version of the product are you using? On what operating system?
3.0.4

Please provide any additional information below.

Original issue reported on code.google.com by muhammad...@gmail.com on 27 Jun 2011 at 9:53

GoogleCodeExporter commented 9 years ago 
See also issue 191.

Original comment by neilboyd on 28 Jun 2011 at 5:27

GoogleCodeExporter commented 9 years ago 
I have the same behaviour. In offline mode, all the cached tiles are deleted 
after a while.

Original comment by elyess.a...@gmail.com on 1 Nov 2011 at 2:47

GoogleCodeExporter commented 9 years ago 
I recently updated to 3.0.5 and this problem remains. I found myself out on a 
survey and without maps.
This issue should be raised to critical in my opinion, since it is not possible 
to avoid it and it can well be seen as a showstopper.

Is there any chance to know if the resolution of this bug is being considered 
or if we can do something to help out?

Thanks

Original comment by andrea.a...@gmail.com on 2 Nov 2011 at 2:03

GoogleCodeExporter commented 9 years ago 
As far as I can see there are only two places where tiles are deleted. So if 
anyone wants to help you could see what are the unexpected conditions that 
cause that to happen.

Original comment by neilboyd on 2 Nov 2011 at 2:20

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
It seems to affect all tiles from all providers (even providers which have not 
been used recently).  So my money's on cutCurrentCache being the culprit.  I'm 
trying to get my head around the lifecycle of mUsedCacheSpace, and when / where 
it should be zeroed...

Original comment by teasel....@gmail.com on 5 Nov 2011 at 4:28

GoogleCodeExporter commented 9 years ago 
Yes, I'm pretty sure the problem is in the handling of mUsedCacheSpace in 
TileWriter.java.  To reproduce the problem, I emptied the tile cache, then 
loaded up 90MB of tiles.  Then started my application and flipped from portrait 
to landscape a few times.  I soon got the following in my Logcat...

INFO/o*.o*.t*.m*.TileWriter(3893): Trimming tile cache from 655943233 to 
524288000

A quick fix would be to add mUsedCacheSpace=0 at the start of the thread, 
before calling calculateDirectorySize().  However, this would have the effect 
of stopping any existing cutCurrentCache threads whenever someone did something 
to re-instantiate TileWriter.  That's probably a less-bad bug than the current 
behaviour, but...

How about passing the usedCacheSpace into cutCurrentCache as a parameter, 
rather than a member variable?

Sorry I've only come up with coding suggestions, rather than providing a 
properly tested patch.  But I've not yet been able to successfully compile 
osmdroid myself. :-(

Original comment by teasel....@gmail.com on 5 Nov 2011 at 4:54

GoogleCodeExporter commented 9 years ago 
Hi, I started last week with Android and OSM and I´ve got the same error (Ver. 
3.0.5).
I think the problem is in the method TileWriter.cutCurrentCache().
This method reads all (physical) files out of the directory TILE_PATH_BASE 
(sdcard/osmdroid/tiles)
final List<File> z = getDirectoryFileList(TILE_PATH_BASE);
This files are sorted into files Array and at the end this (physical) files 
were deleted.
final long length = file.length();
if (file.delete()) <- This is a file at the sdcard, isn´t it?
{
 mUsedCacheSpace -= length;
}
Perhaps there is a real file cache (I didn´t find something) where the tiles 
should be deleted from but not the files in TILE_PATH_BASE.

Something like this:
final List<File> z = getDirectoryFileList(TILE_CACHE_MEMORY);

What do you think?

Original comment by MyWWWU...@gmail.com on 15 Dec 2011 at 9:25

GoogleCodeExporter commented 9 years ago 
I think that TILE_PATH_BASE itself is the cache, that's why tiles gets deleted 
from it.
Anyway I solved this by simply commenting out the file.delete() line. Might be 
a dumb solution but it solved the problem.

Original comment by elyess.a...@gmail.com on 15 Dec 2011 at 2:55

GoogleCodeExporter commented 9 years ago 
During debugging I saw that TILE_PATH_BASE points to the SD Card so it is not a 
(the) cache. 
I think there must be a list with loaded tiles and from this list we have to 
remove the loaded files. 
   tileList.remove(tile)
   mUsedCacheSpace -= tile.length..

Original comment by MyWWWU...@gmail.com on 16 Dec 2011 at 7:59

GoogleCodeExporter commented 9 years ago 
Based on comment 8, it seems like mUsedCacheSpace should be set to zero at the 
start of calculateDirectorySize.

Original comment by neilboyd on 16 Dec 2011 at 8:48

GoogleCodeExporter commented 9 years ago 
Yes comment 8 looks right to me, mUsedCacheSpace is static and the when 
constructing the TileWriter it gets updated in the background.  This is 
presumably happening multiple times without the value ever being zeroed.  I am 
not clear if there are multiple TileWriter objects, if so then the calculating 
of the inital count should realy only happen once.  I Will try and get the 
source building tommorow and work it out.

Original comment by iforpow...@gmail.com on 9 Jan 2012 at 11:35

GoogleCodeExporter commented 9 years ago 
OK I got it building localy today.  Added in some more logging and reduced the 
cache size down to help test.  There looks to be only one instance of the 
TileWriter so just zeroing mUsedCacheSpace before starting the init thread 
looks to solve the issue.  I can flip form portrait to landscape lots of times 
without the cache size growing all the time with the one line fix in.

I am not at all sure about how to go about commiting in, and it's a one line 
fix hopefully someone can do the job.

There is somthing elsewhere badely broken with the tile scaling that looks to 
of gone in, so I will be moveing back to an older jar myself for a bit.

Original comment by iforpow...@gmail.com on 10 Jan 2012 at 4:11

GoogleCodeExporter commented 9 years ago 
If you can attach a patch, or just the modified file, to this issue then I can 
commit it.

Original comment by neilboyd on 12 Jan 2012 at 8:37

GoogleCodeExporter commented 9 years ago 
Sorry totaly missed comment 15 till now....

File attached built under the mavern setup for me just now.

Original comment by iforpow...@gmail.com on 1 Feb 2012 at 6:46

Attachments:

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision r1075.

Original comment by neilboyd on 2 Feb 2012 at 12:56

GoogleCodeExporter commented 9 years ago 
Issue 191 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 6 Apr 2012 at 7:23

GoogleCodeExporter commented 9 years ago 
Hi Folks,

if anybody is interested in avoiding deleting their own tiles cache, I have 
found a suitable
solution. In TileWriter.java @ line 194, you can add the check for your 
directory,
so it will not be cut:
if (file.isDirectory() && !file.getName().equalsIgnoreCase("your directory")) {

The much better way would be to make this configurable ; )

Original comment by k...@njk.aero on 29 Jul 2012 at 11:50

Attachments:

GoogleCodeExporter commented 9 years ago 
Is this issue fixed? If yes kindly inform in which version of osmdroid.

Thanks
Muhammad Babar

Original comment by rajababa...@gmail.com on 5 Feb 2015 at 4:17