Crash while importing Pocketquerry

[Yahp]

Hi Menion,

I am getting a regular crash of Locus Pro with one of my pocketquerries. Others just work fine. GSAK opens the troubling compressed GPX without problems though.

Locus fails at either while importing waypoint 285 or 286. I therefore tried to extract this points from the GPX file and import them on their own. But all GPX with just one single waypoint of those import just fine. I really dont see what I can do here, better for you to look why Locus breaks over this one.

WPT 285 should be the one with <wpt lat="50.946933" lon="11.352433">

Cannot upload the file here (4 M). And the extracts seem to work out. Any way to send you the file?

Thanks and best regards

[Menion]

if you send me it on locus(@)asamm.com, I'll check it tomorrow

[Yahp]

Hi Menion,

sent you the file. Hope you can find something.

Best regards

[Menion]

thanks

imported and all 1000 points without problem. So it should be 1. already fixed issue on your phone, or 2. issue only on your phone (some wrong combination of overwriting, language and who know ...) so please check next market release (hope that tomorrow) and if issue will be still there, create for me log with CatLog program. Thanks

[Yahp]

Will do. Tell you next days what's happening.

Best regards

[Yahp]

Hi Menion,

got the new update of Locus, problem stays the same with old and a new pocketquerry. Sent you catlogfile by mail.

Best regards

[Yahp]

Hi Menion,

got the new update (2.3.4, 13.5.). Behaves the same. Any luck with the log?

Kind regards

[Menion]

Hi,
  unfortunately not. Really weird, but when importing PQ file, seems that android XML parser (used for this task) take really a lot of memory. On non of my testing device, this is not a problem, but seems your device crash on OutOfMemory error (and also no one reported problems with PQ import). I'll try to improve it in some way but cannot promise. Just suggest to reduce required memory in Locus before import (hide point, tracks, overlay maps, wms maps or something like this if you have it enabled ...)

[Yahp]

Hi Menion,

well I now checked with Geobeagle, which also fails during import. Logfile suggest out-of-memory during XML-parsing just like in Locus. Do you think it would be useful to file a report with the androis xml parser team? With Locus I tried as you suggested, all pois hidden, no tracks, no overlays, no wms) does not change anything.

But then again I am very curios, why the import fails with a certain entry in the xml file. That is a different number of the poi in different pocketquerries (weekly updates).

Best regards

[Yahp]

Hi again,

believe it or not. I finally tracked down the troubling cachelisting. It's GC3E8B9 http://www.geocaching.com/seek/cache_de ... a626aa8e7a

The listing on the web (have a look in the source code), the GPX file created for this listing and of course any pocket querry including this listing is 2.4 MB in size. It includes this huge data URI that keeps breaking the import of locus on my phone. As far as the listing of the caches tells other people discovered problems at their garmin devices also.

Although I am still wondering why it works on your phone...

Best regards

[Menion]

Hi,
  very interesting. When owner knows about it, why he don't do something with it?? My phone have a really a lot of memory, so even this can handle, that's only one reason.

[druki]

I can remember having similar problems with an other geocache listing and a symbian geocaching app. I wrote the owner, but he didn't react. So my solution was to correct the gpx file manually to import it once. Then I set the corresponding geocache to my ignore list to keep it away from my pocket queries.
Just a workarround, but maybe this helps.

[Yahp]

Hi druki,

I also wrote the owner and give her some time to fix it. If she does not I might use the workaround you presented. Thanks for the idea

Best regards

[Yahp]

Hiho,

the listing has been corrected. All works well now.
Thanks and best regards.

[Menion]

good news, perfect!