From e26dff149ea21fca2e9b61d93a05476bbcf2532f Mon Sep 17 00:00:00 2001 From: Chuck <33324927+ChuckBuilds@users.noreply.github.com> Date: Fri, 18 Sep 2026 08:37:21 -0400 Subject: [PATCH] docs(sports): state what ESPN_CHUNK_WORKERS was measured to do, not more The comment claimed the sequential fetch made scoreboards blow the 20s startup update() timeout. A boot on this branch still deferred 12 plugins and timed out baseball-scoreboard while its season fetches took 0.74s and 1.12s: the startup budget is spent on other per-plugin work. Say what was measured -- 17.7s sequential, 2.6-3.3s concurrent -- and nothing else. Co-Authored-By: Claude Opus 5 --- src/common/espn_dates.py | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/common/espn_dates.py b/src/common/espn_dates.py index 871378d7..9be705d1 100644 --- a/src/common/espn_dates.py +++ b/src/common/espn_dates.py @@ -46,10 +46,9 @@ ESPN_MAX_LIMIT = 500 # How long a rejected range keeps later ranges from being tried as ranges. RANGE_RETRY_SECONDS = 6 * 60 * 60 -# How many chunk requests may be in flight at once. A cold college-baseball -# season is ~130 chunks once the busy months are re-asked day by day; asking -# for them one at a time took long enough that scoreboard plugins blew the -# 20s update() timeout on first run. Kept under requests' default +# How many chunk requests may be in flight at once. Four busy months of +# college baseball are ~130 chunks once each is re-asked day by day: 17.7s one +# at a time on a Pi 4, 2.6-3.3s six at a time. Kept under requests' default # pool_maxsize of 10 so the shared Session never has to discard connections. ESPN_CHUNK_WORKERS = 6