Some geocache log images refuse to load

Viajero Perdido shared this problem 8 months ago
Solved

Hi. This is something I've noticed in Locus for the longest time. Just now I did a little more investigating.

  • Load a geocache such as GC11C2M. Either via PQ, or Import GC in G4L.
  • Download Logs or Update Cache to load the image thumbnails.
  • Tap the image thumbnail. In GC11C2M, try the image on the most recent log of Sept 25.

Result: image doesn't load, and shows a broken-www icon instead.

This happens reasonably often (5-10% of the time?), and when it does, it happens consistently on both my devices, and (I think) it'll happen from one day to the next. It's as if there's some unknown attribute of certain images that prevents them from loading.

(I thought this was related to the image not having a title, but after some more checking, I realized that's not the case.)

Also, GC3X9P4 has a good mix of loading- and non-loading images.

Comments (20)

photo
1

Good day Viajero,

I'm testing your GPX file and all seems to work correctly for me. Anyway I'm sure in this case, it is not a problem of some specific images in logs, but more general problem in Locus application. I have already noticed few times, that images downloaded from web are sometimes incorrectly displayed as "problem with internet".

I've spend some time on it and probably found a problem that cause this. It will be improved in next version. Same issue may still happen, but I believe it will be a lot more rare. Let me know if this will be better in next version. Thank you.

photo
1

Your lightning-quick replies (and fixes) are always a treat. Thank you!

I'll keep an eye on it in the next version and let you know. Cheers.

photo
1

I did some sofa-testing with the new version, looked at a couple hundred images, and still a few images refuse to load. Maybe 5%. Is it better than before? I think so, but I didn't pay that much attention before the fix.

One thing I've noticed. When an image doesn't load, it's always happens to be the *only* image on the log. (Uninitialized variable?) When a log has multiple images, they always load. And sometimes when a log has just a single image, it will load successfully. BTW, once an image refuses to load, no amount of manual retrying will make it succeed.

photo
1

i´ve also tested behavior,

in one GC-listing most images in loggs are displayed after they are loaded (wifi)

- one image is only as tumbnail visible with my Motorola G3, android 6.01 MM

- exactly this image load pefect with my SGS2 CM14, android 7.0 N

photo
1

Thanks guys, oki, so another improvement in next version ... thanks for now.

photo
1

sorry no improvement with V 3.19.0.1 for my examples

photo
1

Really??? I'm quite surprised as I've changed quite important part to, at least as I thought, 100% working solution :). Give me please a GC code of a cache that has some (better more) images that cause you problems, thanks.

photo
1

GC34CN5 log from 1.1.16 CASImir

GC6TZHH log from 17.10.16

photo
1

GCGH93 has plenty of images. Log of 07.08.2016 by MPofYEG, first image of three doesn't load. Also another image or two farther up that particular page.

Different than before, now I see the problem when there are multiple images on a log. And as before, once it fails to load, no amount of manual retrying seems to help.

Groundspeak's API seems slow today. Sometimes it stalls at the download-logs stage, but a cancel/retry typically works. Maybe sluggishness at Groundspeak is part of the issue...

I also tried the CASImir log balloni55 mentioned above. Didn't load, but (heh), on my phone it showed the date as 31 Dec 2015. (Fun with time zones!) Never mind that.

In the second example mentioned above, the non-balloni55 log of that date didn't load. (balloni55 also has a log on that date, it did load.)

This is all with today's new beta. BTW, the new font size for logs is perfect, thank you.

photo
photo
1

Thanks guys! I was thinking that problem is in small thumbnails, but seems that issue is in big images, right? Anyway

@balloni55 ,

image in GC34CN5 ( https://s3.amazonaws.com/gs-geo-images/6be40adc-c961-4b88-ab79-5832749c4aa1.jpg ) , image has incorrectly set color palette and also it's PNG, not JPG image. Some tools display it, unfortunately seems that Android don't, sorry.

image in GC6TZHH ( https://s3.amazonaws.com/gs-geo-images/92662631-2fab-49e0-93a0-12c0225be874.jpg ), same problem, hmm

@Viajero Perdido:

first image in GCHG96 log ( https://s3.amazonaws.com/gs-geo-images/47458d09-7794-4535-b4cb-b6db623dae1b.jpg ), exactly same issue.

I've used this tool : http://regex.info/exif.cgi to check what's wrong.

---

Hmm after some more searching, I've found that images are probably in color palette defined as CMYK, which is not by default supported by Android! Even a QuickPic (my favorite image browser) refuse to open it.

I've found only solution, by using some quite old library ( https://github.com/Mariovc/GetCMYKImage ) which is also unfortunately compiled only for one type of processor.

So I'm sorry guys, this issue do not have solution because main problem is in Android itself.

photo
1

thanks for your description ;-))

as i wrote above:

- exactly this image load pefect with my SGS2 CM14, android 7.0 N

so it didn´t depend generally on android

photo
1

On Android 7+? Then there is a chance that it's fixed in new version of Android, or maybe in CM ROM.

photo
1

It work also on CM13, so i suspect the ROM

photo
photo
1

This issue is with the big images, not the thumbnails, right. Thumbnails always load.

I'm running the latest stock Android 6 on both my devices.

I wonder if Groundspeak's own app has the same problem. Maybe they could be persuaded to fix up the images on their server, hmm... (I won't ask you to do that.)

BTW, I know the http://regex.info/exif.cgi tool well; it's my favourite resource for solving puzzles.

Thanks for all your efforts on this. :) I can live with it.

PS, one last thought. Some of the problem images are huge PNGs. Could it be as simple as them taking too long to load?

photo
1

I just discovered this problem has a serious side-effect. After an image fails to load. Locus starts using data at an incredible rate.

  1. Make sure you're on WiFi (to save €).
  2. Load a cache via PQ with a known problem image. GC5A79 triggered it for me, most recent (2016) image.
  3. Go "Download Logs".
  4. Tap the image thumbnail.
  5. After a few seconds, you see the tiny broken-image icon.

Result: Locus is now consuming data for unknown reason, and continues doing so until you exit Locus completely.

I measured about 1MB / second (!!!) on WiFi, and unknown speed on cellular (I hit my data cap almost immediately; I had kept it low so it only cost me a few dollars.) But I calculate that with my data plan, if I hadn't set a limit in Android, this would cost the equivalent of about €70 / hour. It also used about 1GB over WiFi at home before I noticed, and while I tracked down the issue.

This happens on both my devices (one is different than the time of my earlier report above; all three with Android 6.0), with three different caches where I'd found problem images. I'm using offline vector maps, G4L is not active, not using Live Tracking. Data drains whether Locus is foreground or background, and Android identifies Locus as the culprit. Happens with Locus 3.23.2, also beta 3.23.2.3.

Sorry, but Locus is now on my short list of apps not allowed to use background data on cellular. And my apologies if you're still trying to be on vacation; I hate to disturb a well-deserved break.

photo
1

Good day Viajero,

thank you for a precise description. Yes I'm on vacation, but because I do not have here an computer, I only solve some easy tasks on my wife's notebook.

Nice serious issue! I'll look at it in Sunday once I return home, thanks!

photo
1

No worries; enjoy the break. :)

I'm sure that once you're sitting in front of your tools, you'll have identified the problem within minutes. In the meantime, I'll just be careful around images.

I may be off-grid Sunday for a few days.

photo
1

Good evening Viajero,

I think I have found reason for this issue, but to be true ... I'm not 100% sure. There seems to be an function that called repeatedly loading of this "invalid" image, but even on older devices, this happen to me just twice.

If you will find time, try please next Beta version and let me know. New Beta should be out during next week. Thank you.

photo
1

I'm happy to say, the data usage is fixed in beta 3.23.2.5! That was fast. :)

I retried the procedure above with both my devices, and while the problem images still didn't load (I can live with that), there was no sudden data usage afterward.

photo
1

I'm really glad to read your post, perfect. Thank you for a precise bug report and mainly tests you made!

photo