Latency check: persist results and refresh only when stale #206

New issue

Open

opened 2026-08-29 13:13:49 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-29 13:13:49 -04:00

Owner

Latency results are cached today only by accident:

They live in the in-memory server dicts and order the next check (fastest first), but reach server.json only on a clean gui shutdown.
A provider re-import - including every 5-day auto-update - drops that provider's stored latencies whole: merge_import copies favourites onto the fresh table but not latency.
Startup therefore re-pings everything from an alphabetical list every time.

Make it deliberate:

Persist latencies with a timestamp.
At startup, show cached values immediately (instant sort), then refresh in the background only when the cache is stale or the network changed. Latency is a property of the current network, which is why network-change is already a trigger - it stays the invalidation event, not the auto-update cadence (5 days is the wrong TTL for network conditions; the auto-update already implicitly invalidates the provider it refreshes).
Carry latency over in merge_import the way favourites are, so an auto-update doesn't scramble the sort order for unchanged servers.

Companion to #205 (speed of the check itself).

Latency results are cached today only by accident: - They live in the in-memory server dicts and order the *next* check (fastest first), but reach server.json only on a clean gui shutdown. - A provider re-import - including every 5-day auto-update - drops that provider's stored latencies whole: merge_import copies favourites onto the fresh table but not latency. - Startup therefore re-pings everything from an alphabetical list every time. Make it deliberate: - Persist latencies with a timestamp. - At startup, show cached values immediately (instant sort), then refresh in the background only when the cache is stale or the network changed. Latency is a property of the *current network*, which is why network-change is already a trigger - it stays the invalidation event, not the auto-update cadence (5 days is the wrong TTL for network conditions; the auto-update already implicitly invalidates the provider it refreshes). - Carry latency over in merge_import the way favourites are, so an auto-update doesn't scramble the sort order for unchanged servers. Companion to #205 (speed of the check itself).

mysticalsoap added the

label

2026-08-29 13:13:49 -04:00

mysticalsoap referenced this issue

2026-08-29 13:13:55 -04:00

Server tab: button to force a latency re-check #207

mysticalsoap referenced this issue

2026-08-29 14:16:56 -04:00

Overhaul server metadata (country system, tiers, features) #52