The only values KickStreamer.thumbnailWaitSeconds will accept, in seconds. null is the default.
── THESE ARE EXTRA SECONDS, NOT A TOTAL ────────────────────────────────────
Every Kick creator already gets a ten second baseline: the go-live thumbnail is probed instantly,
again at 3s and again at 10s, and past that the notification ships a fallback image which a delayed
repair edits to the real thumbnail. This setting buys a creator MORE time than that, so 30 is a
40 second ceiling and 10 is a 20 second one.
So label the control accordingly: "30 seconds" is wrong, "+30s" is what it does. And null is not
"do not wait" - it is the ten second baseline everyone gets. Both of those read as the total to a
user, and neither is.
Fallback only. The API now serves thumbnailWaitOptions on the Kick platform response; read
that where it exists and use this when it does not. A constant copied by hand from a list that
lives somewhere else is a rule that drifts, which is exactly why the API publishes it now.
── THE SENTENCE THAT MATTERS FOR THE CONTROL ───────────────────────────────
thumbnailWaitSeconds is stored per GUILD but applied per CREATOR. The thumbnail is resolved once
and fanned out to every guild tracking that channel, so the LONGEST value among all of them wins.
A server's own choice can therefore be silently overridden by another server's, and its choice can
silently slow everyone else down. Say so in the control's help text - without it the setting reads
as a private per-server preference, which it is not.
A fixed set rather than a free number for the same reason: an open field would let one server hold
up every other server's notification for that creator.
The only values
KickStreamer.thumbnailWaitSecondswill accept, in seconds.nullis the default.── THESE ARE EXTRA SECONDS, NOT A TOTAL ──────────────────────────────────── Every Kick creator already gets a ten second baseline: the go-live thumbnail is probed instantly, again at 3s and again at 10s, and past that the notification ships a fallback image which a delayed repair edits to the real thumbnail. This setting buys a creator MORE time than that, so
30is a 40 second ceiling and10is a 20 second one.So label the control accordingly: "30 seconds" is wrong, "+30s" is what it does. And
nullis not "do not wait" - it is the ten second baseline everyone gets. Both of those read as the total to a user, and neither is.Fallback only. The API now serves
thumbnailWaitOptionson the Kick platform response; read that where it exists and use this when it does not. A constant copied by hand from a list that lives somewhere else is a rule that drifts, which is exactly why the API publishes it now.── THE SENTENCE THAT MATTERS FOR THE CONTROL ───────────────────────────────
thumbnailWaitSecondsis stored per GUILD but applied per CREATOR. The thumbnail is resolved once and fanned out to every guild tracking that channel, so the LONGEST value among all of them wins.A server's own choice can therefore be silently overridden by another server's, and its choice can silently slow everyone else down. Say so in the control's help text - without it the setting reads as a private per-server preference, which it is not.
A fixed set rather than a free number for the same reason: an open field would let one server hold up every other server's notification for that creator.