Should be a bit cleverer handling download errors

[GoogleCodeExporter]

If there's an error downloading a map tile then it should be a bit cleverer 
about retrying.  In some cases the error may go away when retrying, and in 
others it may be permanent. In the case of permanent errors there's not much 
point immediately and repeatedly requesting the same tile again. However 
since it's difficult to know whether the error is permanent we shouldn't stop 
attempting altogether.

See also issue 7 and issue 28.

Original issue reported on code.google.com by neilboyd on 26 Mar 2010 at 3:08

[GoogleCodeExporter]

Original comment by neilboyd on 15 Apr 2010 at 2:12

[GoogleCodeExporter]

See also issue 56.

Original comment by neilboyd on 4 Jul 2010 at 12:52

[GoogleCodeExporter]

We had massive problems caused by this behavoir. When using our own customly 
rendered tiled-overlays for some parts of the map it made the map unresponsive 
at the borders of our custom layer.

Our first dirty fix:
- In case of an download error we write a tiny maptilename.png.err-file on the 
SD-card. So it won't load this tile again and again. But this is just a 
quick'n'dirty fix for our issue.
- I'd like to implement a "timeout" for the error-tiles through the 
last-modified-attribute so those tiles can be reloaded after some time. I'll 
then commit this patch - probably around next week

Original comment by janrose....@googlemail.com on 9 Jul 2010 at 6:58

[GoogleCodeExporter]

This sounds like a good fix. You bear in mind the points made in the issue 
description, ie that we want to try again some time but not too often.

Maybe you could just write the png with 0 size.  There is other code to prevent 
that happening, but perhaps we could use that as an indicator for different 
behaviour, ie try again, but only after some time.

This fix can probably be combined with issue 40.

Original comment by neilboyd on 9 Jul 2010 at 8:44

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Original comment by neilboyd on 15 Sep 2010 at 2:32

• Changed state: Started

[GoogleCodeExporter]

Done a (partial) fix in revision 369.

Original comment by neilboyd on 15 Sep 2010 at 2:57

[GoogleCodeExporter]

First up, a quick shout out to the developers. I love this library! Well done.

I agree with the other reporters here and would add the following comments.

If there's a problem downloading a tile check for a full file system as a 
possible root cause. If the sdcard is full then osmandroid could delete the 
least recently used tile or perhaps throw an exception? 

At present it spins CPU and spams the log file with seemingly infinite repeated 
attempts to download tiles. Makes the an app laggy and when debugging, the 
logcat view in DDMS loses the plot.

Thanks again for the library, love it.

Original comment by rob.kie...@gmail.com on 19 Sep 2010 at 6:24

[GoogleCodeExporter]

This issue was closed by revision r379.

Original comment by neilboyd on 21 Sep 2010 at 2:27

• Changed state: Fixed

[GoogleCodeExporter]

Thanks Neil. Will download the update tomorrow.

Original comment by rob.kie...@gmail.com on 21 Sep 2010 at 11:17

[GoogleCodeExporter]

See also issue 93.

I've marked this as fixed, but I'd appreciate if someone could confirm that it 
works on a 1.x device. The behaviour of the media state listeners is different 
on 1.x and 2.x.

Original comment by neilboyd on 22 Sep 2010 at 5:01