Mod Management Menu Never Finishes Loading

[carriontrooper]

Mod Management Menu Never Finishes Loading

[SomeTroglodyte]

Works fine for me. You're either having a very low bandwidth, or packet losses, or you're nailing github until the rate limit kicks in.

That said, I did think about some way to show when the rate limit is blocking the query, but had no nice idea how.
Also ties in with my investigations into GraphQL - which has vastly different rate limits, vastly better bandwidth usage, easier access to correct rate limit info, but also vastly nastier requirements - as in mandatory OAuth.

[carriontrooper]

Problem is, it worked just fine in versions prior to 4.9.19. - filtering menu loads in seconds, whether via phone or PC, using phone packet data or laptop wifi. I don't think it's the rate limit that's causing the issue.

[SeventhM]

4.10.3 patch 1 on my phone. Loads just fine for me. Just takes some amount of seconds to load. So can't reproduce here

[carriontrooper]

Hmm, I haven't updated it to patch 1, let's see if that fixes things

[SomeTroglodyte]

Is that loading symbol turning? Du you have the "continuous rendering" option on? Should be visual only, but maybe it influences some events/actions processing.. Question valid for Phone + as you say "Problem also exists on PC version". What else do your boxes have in common that may be different from ours?

[SomeTroglodyte]

Just tested again, this time on Android hardware. With and without "continuous rendering", landscape and portrait. The query always finishes, filtering and sorting get enabled just fine. With such repetition of course I hit the rate limit, so the last test needed 40 seconds to finish.

It even logged Unciv RateLimit com.unciv.app D [threadpool-daemon-0] GitHub API Limit reported via http (60) not equal assumed value (10) - which may be a hint. I don't remember clearly, but I think the ratelimit handler operates on assumptions taken from the documentation at the time. If github changed the rules, the code may not predict properly when the ratelimit will hit, and take longer than maybe needed. But then - that message says the limit is more generous than assumed... But the docs still say 10 requests per minute, which are the values the code uses...

Are you able to do the query normally from a browser?
https://api.github.com/search/repositories?q=%20topic:unciv-mod%20fork:true&sort:stars&per_page=100&page=1
would be the first page. Should return pretty quickly. But as you can see, there's 641 mods therefore 7 pages, meaning if you open mod manager twice and let the queries finish within a minute you're already hitting the documented rate limit.

I still say it's your network stack. Probably a shared external IP so other people contribute to the same rate limit.

[SeventhM]

Is that loading symbol turning?

Uh... Is it supposed to turn? I don't think I've seen it do so

[SomeTroglodyte]

supposed to turn

Of course it's animated - unless you turned animation off - with this setting.

[SeventhM]

Looks like it's off by default

[SomeTroglodyte]

Looks like it's off by default

Looks like you're right! I never noticed... The default has been turned off with ... #1996, looong ago - but why?

[carriontrooper]

Is that loading symbol turning? Du you have the "continuous rendering" option on? Should be visual only, but maybe it influences some events/actions processing.. Question valid for Phone + as you say "Problem also exists on PC version". What else do your boxes have in common that may be different from ours?

Loading symbol is not turning on both machines, and it's definitely not a bandwidth throttle since I can play War Thunder and other bandwidth-heavy games on my PC just fine without lags. So that rules it out on PC.
Continuous rendering I haven't touched since installing the game long ago, it's off.

[carriontrooper]

Just tested again, this time on Android hardware. With and without "continuous rendering", landscape and portrait. The query always finishes, filtering and sorting get enabled just fine. With such repetition of course I hit the rate limit, so the last test needed 40 seconds to finish.

It even logged Unciv RateLimit com.unciv.app D [threadpool-daemon-0] GitHub API Limit reported via http (60) not equal assumed value (10) - which may be a hint. I don't remember clearly, but I think the ratelimit handler operates on assumptions taken from the documentation at the time. If github changed the rules, the code may not predict properly when the ratelimit will hit, and take longer than maybe needed. But then - that message says the limit is more generous than assumed... But the docs still say 10 requests per minute, which are the values the code uses...

Are you able to do the query normally from a browser? https://api.github.com/search/repositories?q=%20topic:unciv-mod%20fork:true&sort:stars&per_page=100&page=1 would be the first page. Should return pretty quickly. But as you can see, there's 641 mods therefore 7 pages, meaning if you open mod manager twice and let the queries finish within a minute you're already hitting the documented rate limit.

I still say it's your network stack. Probably a shared external IP so other people contribute to the same rate limit.

Yeah I can open the page just fine using my phone just now, chrome browser. I'll see if turning continuous rendering on fixes this thing.

[carriontrooper]

Well, the arrow does rotate, but I've waited more than 5 minutes and the filter dropdown didn't appear at all.

The bottom-most mod on the list (sorted by stars iirc) was the Arknights Firewatch mod, as of writing this.

[SomeTroglodyte]

So that rules it out

Not necessarily. Server, provider routing, external firewalls can still make one server slow while another is fast. But let's assume transport to be fine.

turning continuous rendering

Well, we established the animation is purely cosmetic as it should be. If it were frozen while the option is on, that would have been another matter.

So, if we can't reproduce, how should we be able to investigate? The one who can repro can analyze...
Does the console and/or logcat say anything interesting maybe a minute or two into mod manager?

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days.