Downloading stopped working a few days ago with "Cannot parse result".

[GoogleCodeExporter]

What steps will reproduce the problem?
 1. Whilst still in "Offline' mode, navigate to a region that you have not already downloaded until you see the grey squares with "We are sorry, but we don't have maps at this zoom level...".
 2. Uncheck the "Offline" box to go online to download the tiles.

What is the expected output? What do you see instead?
The grey tile(s) go blank and the program connects to Google as expected, then 
an endless loop of those blank areas flickering repeatedly between grey and 
blank. CPU usage goes up to 100%.

To end the loop just go offline again by checking the "Offline" box.

What version of the product are you using? On what operating system?
GMapCatcher-0.7.2.0 on Mandriva Linux 2010.1 and Python 2.6.5.

Please provide any additional information below.
When run from a terminal:
[quote]
$ ./maps.py

Cannot parse result
Debug: <type 'exceptions.TypeError'>argument 1 must be string or buffer, not 
None<traceback object at 0x7f65db7dc4d0>
        download failed - <type 'exceptions.TypeError'>
File corrupted: /home/user/.googlemaps/tiles/5/3/972/2/453.png
Quit
[/quote]

This was working fine until a few days ago and I have been using this version 
since 30 July 2010.

Hope this can be fixed easily because this program is THE BEST!  Thanks.

Original issue reported on code.google.com by shar...@gmail.com on 11 Aug 2010 at 8:46

[GoogleCodeExporter]

I notice that same behavior using my laptop on the road with no Internet 
connection the   drawing area was flickering like you describe, very strange...

Original comment by heldersepu on 11 Aug 2010 at 11:41

• Changed state: Started
• Added labels: Milestone-Release0.75

[GoogleCodeExporter]

Original comment by heldersepu on 12 Aug 2010 at 1:05

[GoogleCodeExporter]

I see that this issue was introduced back in r860:
http://code.google.com/p/gmapcatcher/source/diff?spec=svn860&r=860&format=side&p
ath=/trunk/maps.py

Original comment by heldersepu on 12 Aug 2010 at 1:10

[GoogleCodeExporter]

I noticed that mainly when the layers were changed to a setting that was 
incoherent; such as hybrid layer for virtualearth for instance; the coherence 
of the layers was modified after 0.7.2.0; I seem to think I have noticed 
similar behavior from cloudmade - in onedirpermap mode - even now though;

download failed -Debug: <type 'exceptions.NameError'>global name 
'cloudMade_styleID' is not defined<traceback object at 0x1f8e638>

although that may be more of a parallel bug than identical, parallel as the 
symptoms are similar, non-identical as the root cause is no longer the obsolete 
r860 code, it is a namespace error - namespace error now resolved in r958 as 
we're thinking of it :-)

sharrea, have you retried from svn 0.7.2.2?

Helder, some/most of that code from r860 is obsolete now - hopefully! - 
MainWindow.downloading refers to MainWindow.downloader.qsize() more directly 
now rather than doing its own sums - the qsize() may be giving inaccurate 
results? Notably when there's an error

Original comment by Mark111...@gmail.com on 12 Aug 2010 at 7:56

• Added labels: Usability

[GoogleCodeExporter]

Mark111111:  No I haven't tried the svn version.  Will do so and report back.  
Cheers.

Original comment by shar...@gmail.com on 12 Aug 2010 at 10:08

[GoogleCodeExporter]

I guess that in r860 we are creating an infinite loop when the tiles fail to 
download:
http://code.google.com/p/gmapcatcher/source/browse/trunk/maps.py?spec=svn958&r=9
57#733

Original comment by heldersepu on 12 Aug 2010 at 2:12

[GoogleCodeExporter]

Sorry guys, my problem is solved and GMapCatcher was NOT the problem. As it 
turns out my ISP was blocking Google Maps but all is fixed now. And BTW svn 
works also but my original version 0.7.2.0 is working again anyway. I really 
apologise for any time wasted... well at least you found the infinite loop.

Original comment by shar...@gmail.com on 12 Aug 2010 at 10:26

[GoogleCodeExporter]

Good for you, but we did have a small problem the flickering should not happen.

Original comment by heldersepu on 12 Aug 2010 at 11:56

• Changed state: Fixed

[GoogleCodeExporter]

Sharrea, no need for apologies, your bug report was entirely justified, well 
documented, provided sufficient detail, has given us the impetus to make the 
necessary connected improvements so that hopefully nothing similar happens in 
future :-)

Original comment by Mark111...@gmail.com on 13 Aug 2010 at 8:33