Streetcomplete: Map delayed display

[DennisKempel]

on app start map displays after about 35 seconds only. seems to be the case on every app start after it has been closed. has been a lot faster (immediate displaying) before.

close app (whipe out of app list), open it again

Versions affected
latest stable

[matkoniecz]

Is it possible that your phone entered some power-saving mode? On my Xiaomi it was bungled (like entire phone) and caused all kinds of breakage across various apps, usually manifesting as extreme lag/slowdown/performance loss.

[matkoniecz]

latest stable

Which one? For example F-Droid has extreme delay in releases.

It is listed in top of "about" menu.

[peternewman]

Yes! :100:%

From a different issue:

I was going to say I feel like I've had similar slow responses since the switch to Jawg. Certainly when offline it takes a lot longer to time out and switch to my cached tiles than it used to.

But also at times when online they seem to load far more slowly. Both SC and the web app are currently very responsive again right now, but SC seemed slow a few hours ago.

_Originally posted by @peternewman in https://github.com/westnordost/StreetComplete/issues/2089#issuecomment-695358603_

I also see it if I accidentally hit back twice and end up out of the app that way, which is even more annoying if you're mid surveying.

Mine is ~when the device is offline~ all the time so I think it's trying to timeout before it displays cached content, or possibly timing out at lots of layers, but it wasn't anywhere near that slow on the old provider.

I get the quest icons immediately. For me the delay is more like 45 seconds. Currently on v24.0, Android 9 on a Sony, Google Play store.

You're not low on space are you @DennisKempel ?

[DennisKempel]

Hi, got space enough. Google Pixel 3, many gigs left.

start of JawgMaps was great, zero lag, up to date maps. a few commits later behaviour changed, do not remember when exactly.

i do not think it has to do with power saving or anything as it happens always, independent of phone mode, battery charge or anything else. Maps always appear, it just takes ~30 seconds after start of app. It does not happen when i switch between apps and return to SC.

[DennisKempel]

I'm on v24.0 - since a few minutes on 24.1, same behaviour on start. I tried switching map cache was 250mb, set it to 200mb, still the same.

[westnordost]

What do you mean, "a few commits later"?

So, we use Jawg since v21.0-beta1. Maybe you could uninstall and install that old version again, see if you can reproduce that problem and then upgrade version by version until you can reproduce it? That would help me find which change did introduce this problem.

[DennisKempel]

I mean it wasn't there when you started with Jawg. In the beginning it was lightning fast.

unfortunately I do not know how to install old versions. I got mine from play store, there seem to be no old versions.

[westnordost]

Here on github
https://github.com/westnordost/StreetComplete/releases

You can download and install the APK

[matkoniecz]

You can download and install the APK

If you never did this before you will need to enable installing APK files in settings. Note that random people / malicious ads / etc asking to install APK files sometimes do this do get malware on your phone (it is not happening in this case).

[peternewman]

So, we use Jawg since v21.0-beta1. Maybe you could uninstall and install that old version again, see if you can reproduce that problem and then upgrade version by version until you can reproduce it?

Or do a binary search/bisection, which will be a bit quicker. So trying something in the middle of the potentially affected ones, and then if its fine splitting the later ones, if it's broken splitting the earlier ones etc. Then we should get an answer a bit quicker.

I've marked some we know are faulty based on now and my comment in https://github.com/westnordost/StreetComplete/issues/2089#issuecomment-695358603 (and what the changes I'd made then were tagged as).

• [x] v25.0-beta1
• [ ] v24.2
• [x] v24.1
• [x] v24.0
• [x] v24.0-beta1
• [x] v23.0
• [x] v23.0-beta1
• [ ] v23.0-alpha1
• [ ] v22.3
• [ ] v22.2
• [ ] v22.1
• [ ] v22.0
• [ ] v22.0-beta1
• [ ] v21.2
• [ ] v21.1
• [ ] v21.0
• [ ] v21.0-beta1

[westnordost]

The vector tile provider switched tiles starting with v25.0-beta1. You might want to check if the problem remains for the new versions. Apparently, the tiles are even smaller than before.

[peternewman]

Still the same for me unfortunately @westnordost .

[DennisKempel]

Play Store days beta program is full 🤷🏻‍♂️

[peternewman]

Play Store days beta program is full 🤷🏻‍♂️

You can always download an install the APKs directly @DennisKempel :
https://github.com/westnordost/StreetComplete/releases

[DennisKempel]

Note: today the map appears immediately upon app start again. Not sure if you made any changes of course, but maybe it is rather an JawgMaps issue.

I'm still on latest stable and did not change anything.

[peternewman]

Is it still fast for you now @DennisKempel ? It's still slow for me now.

Did you change anything your end e.g. different network/location, cleared space on device etc?

[DennisKempel]

No, haven't changed anything in my home network or the app. Also today morning still fast, max 1 second before maps display. v25.1
sorry, @peternewman

[westnordost]

Where are you using the app? Maybe it is some delivery network problem, something based on your location.

[DennisKempel]

It is not connected to location or network. It did not work on WiFi (Hamburg, Germany), not on 4G wherever I went (traveling often) or on guest WiFi or anywhere. Misbehaviour was quite constantly. now it's back to normal and quite constantly as well, on any network type.

no clue what is different.

[westnordost]

I'm also in Hamburg. Hm.

On 6 November 2020 20:26:01 CET, Dennis [e-mail] wrote:

It is not connected to location or network. It did not work on WiFi
(Hamburg, Germany), not on 4G wherever I went (traveling often) or on
guest WiFi or anywhere. Misbehaviour was quite constantly. now it's
back to normal and quite constantly as well, on any network type.

no clue what is different.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/westnordost/StreetComplete/issues/2142#issuecomment-723257516

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[peternewman]

I've used it in two different parts of London at least, but probably always SE England. Generally on WiFi but from at least three different suppliers and definitely two different peering points. Mine is still consistently slow.

@westnordost I guess firstly what domain does it get results from (I'm wondering if there is some DNS localisation going on). Alternatively if you try an open it when positioned around Euston station in North London is it slow? Are there any logs I can easily get from the device or will I need to fire up Wireshark?

Edit: I've just tried starting up centred on Hamburg and it's still slow for me. :confused:

It displays promptly via:
https://ent8r.github.io/streetcomplete-mapstyle/

On the same WiFi and even on the device itself!

[westnordost]

I think we still need more information. To summarize, for some users, map tiles from JawgMaps download very very slowly. Others do not have this problem at all. We did not find out yet why it is slow for some people and fast for others. What we found out so far:

• it has something to do with the served JawgMaps tiles (i.e. there was no problem with nextzen tiles)
• it is not dependent on the viewed location
• it is not dependent on the local wifi/mobile connection
• it is not dependent on the used device or Android version
• it is not dependent on the JawgMaps tileset used. I.e. the problem persists with both streets and streets-v2 layer
• it seems to be dependent on either the used JawgMaps API key or tangram-es: @peternewman reports that https://ent8r.github.io/streetcomplete-mapstyle/ displays promptly for him while the map in StreetComplete doesn't. The only difference between these two is that they use a different JawgMaps API key and that one uses tangram-es to download and display the tiles, the other uses tangram (JS) to download and display the tiles.

So, maybe it has to do something with the JawgMaps quota of the API key used for StreetComplete? ~End of every month, I am getting a quota warning via email saying

Hello Jawg user,
You have reached 90% of your maps quota for the period from October 14, 2020 to November 14, 2020.
You can check your consomation on jawg lab.

@Joxit told me that I can ignore these emails as the quota is not enforced for this API key. But maybe some other internal implementation is triggered which somewhat throttles tiles being served. So, I am pinging him, maybe it is a bug in JawgMaps or some problem with DNS localization as @peternewman suspects.

[peternewman]

Hello Jawg user,
You have reached 90% of your maps quota for the period from October 14, 2020 to November 14, 2020.
You can check your consomation on jawg lab.

@Joxit told me that I can ignore these emails as the quota is not enforced for this API key. But maybe some other internal implementation is triggered which somewhat throttles tiles being served.

So the quota resets every 14th? If I remember I'll try accessing it on the 15th and see if it's better then, which in theory it would be if it wasn't being restricted.

Actually I'm wondering if it's not Jawg but tangram-es because it takes the same time, or possibly slightly longer, to display it when in airplane mode (i.e. using my cached offline map). Which clearly can't be relying on any API limiting but could be hitting HTTP timeouts in tangram-es? I do see the map before I get a GPS lock, so it's not related to that in any way.

[Joxit]

Hi there, this issue is still present ?
This should not be linked to the quota, but you can still try.

[peternewman]

It is for me today still, which I think confirms the ruling out of the quota thing. Although as mentioned given it happens offline it feels like it must be a timeout within tangram-es or similar.

[smichel17]

I encountered this yesterday. I am not sure if it was a problem with downloading or rendering with tangram but in either case I am pretty sure this is not a jawg bug @Joxit. It's either in SC, Tangram, or Android itself. Here's what I did:

• Open app as I am walking out the door.
  
  
  
  • How was not enabled previously, and the app opened at world view. This surprised me, since last week I was using it to map this area and I haven't opened it since, not cleared the app's cache or data.
  
  
• Turn on gps, continue walking away from the house
• While waiting for a gps fix, start manually zooming in on my approximate location. Two important things to note:
  
  
  
  1. The area where I was actually walking around, should have been cached, since I have my map cache set to 250MB and I had gone surveying in the area 6 days earlier
  
  
  2. My manual zoom in was imprecise -- it took me to areas that were not cached.
  
  
• My phone got a gps fix just as I was at the edge of wifi range (still connected to the wifi network, but no actual connectivity to the Internet)
  
  
  
  • Streetcomplete jumped to my position, but the background map was not rendered. At the same time, it started trying to search for quests.
  
  
• I continued walking and moved out of wifi range altogether
  
  
  
  • Neither the map render nor the quest download completed
  
  
• I waited around a minute.
  
  
  
  • Again, neither completed
  
  
• I killed the app (swiped away from recent apps screen) and re-opened it.
  
  
  
  • SC opened at my position and the map rendered instantly.
  
  
• I manually chose "scan for quests here" and chose to replace the current scan. The new scan worked.
  
  
  
  • I may have done this before restarting the app; I don't remember.
  
  

This is a fairly common problem: network requests started on wifi will not be retried on 4g if you disconnect from wifi before a response is received.

However, the speed that SC rendered at after I restarted it suggests that the local tiles were in fact already cached, but SC was waiting on the completion of an unrelated network request to render them.

[westnordost]

Yeah, this is a common problem. Not sure exactly what happens when you move out of wifi range, probably a timeout. And timeouts may take very long to "finish" - it's basically the client's choice how long he want to wait for an answer before it gives up. So, pretty sure what happened with the quest download is that the app still waited for a reply from wifi. StreetComplete just uses the default timeout times from the Java URL-API, not sure how much that is.

The tile requests are handled by tangram-es.

[smichel17]

So, this seems like probably a tangram bug. A network timeout for tiles at location 1 should not block a render at location 2, if there are already cached tiles for location 2.

[DennisKempel]

Note, for me the problem existed while being _permanently_ on WiFi or on mobile connection. However, it is gone now, for whatever reason.

[westnordost]

Could someone try if he or she can reproduce the issue by f.e. turning off the wifi router or something so that it runs into a timeout?