'Unknown error' or 'Server query timed out' preventing stops from loading

[gy-mate]

Problem

1. I open the app while having a wifi or 5G mobile network connection
2. The loading process of stops begins https://github.com/user-attachments/assets/fddfbb9b-506f-4ee2-a924-7f51c37bb401
3. They do not load even after 30 seconds
4. Sometimes I get an ‘Unknown error.’ and/or ‘Error: Server query timed out.’ warning

Which app version do you use?

0.8.0+19

What operating system do you use?

iOS

What operating system version do you use?

17.6.1

Additional information

No response

[Robbendebiene]

Thanks for the detailed report. We look into it.

[7h30n3]

Thanks for using the app and creating an issue. Unfortunately, I can't reproduce the error on our testing iPhone and in the iOS Emulator. I'm running iOS 18.0 on the physical phone and iOS 17.5 on the emulator.

So I guess it must have something to do with the connection speed. Although you are using Wifi and 5G 🤔

[gy-mate]

@7h30n3 I don't think that it's about the connection speed. I've just re-tested this on a 480/40 Mbps wifi connection (ping: 13 ms; jitter: 2 ms; packet loss: 0,00%)—it loaded, but it took 53 seconds. And on a a 490/25 Mbps 5G mobile network connection (ping: 18 ms; jitter: 3 ms; packet loss: 0,55%) it took 1 minute and 7 seconds. I find that a bit slow.

[Robbendebiene]

@gy-mate Thanks for the details. When you say "the loading took x seconds" do you only refer to the loading indicated by the red circles or the "searching animation" (the magnifier) as well? Can you perhaps make a short screen recording of the whole process?

[gy-mate]

Can you perhaps make a short screen recording of the whole process?

@Robbendebiene You can find screen recordings on the embedded links in my previous comment.

[Robbendebiene]

@gy-mate Sorry my bad 🫣

So this is a different problem than the original issue, where the actual query of the elements at the stop failed.

The magnifier indicates that nearby stops (just their locations and names) are being queried. This can take longer in bigger cities due to the amount of data the overpass server has to process (not because a lot of data is transmitted). Admittedly this is not ideal and is mainly introduced by https://github.com/OPENER-next/OpenStop/pull/262 We could think about caching loaded stops (not the actual elements). Maybe the underlying overpass query could also be improved (ideally overpass would have something like DBSCAN).

Coming back to your original issue, if you find a place where you can reproduce the "Unkown error" we would be eager to know about it.

[matheusgomesms]

I'm facing similar issue (iOS, latest version). Sometimes it takes a looong time to download the data, and sometimes I give up (although I never faced the "unknown error). No internet problem here.

[Robbendebiene]

@matheusgomesms When you refer to "download the data" you mean the magnifier animation takes a long time?

[matheusgomesms]

@matheusgomesms When you refer to "download the data" you mean the magnifier animation takes a long time?

Yes, there are mainly two cases, which I don't know if it's related to this issue or we can discuss in a new one.

1 - magnifier gets spinning for a long time (10-30 seconds) but it works 2 - it gets spinning forever and nothing appears later. I have to shut down the app and open again.

Question: does OpenStop only works when around a PT station?

[gy-mate]

So this is a different problem than the original issue, where the actual query of the elements at the stop failed.

if you find a place where you can reproduce the "Unkown error" we would be eager to know about it.

@Robbendebiene Alright, I'm closing this one and opening a new issue for the slow loading.

[Robbendebiene]

@matheusgomesms Sorry I missed your reply.

Question: does OpenStop only works when around a PT station?

Yes kinda. The magnifier searches for all nearby stops/platforms and clusters them into stop areas. Then it loads all elements in this area. I think both your mentioned issues have the same underlying cause.

@gy-mate Thanks. We'll continue discussion over there.