You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The getStreams endpoint used for getting the time a streamer went live has some inconsistencies - tbd if this is on the API end or the logic currently on the API.
This endpoint returns a UTC timestamp started_at which is comapred against a Date.now() timestamp, and logic is in place to get the differential in minutes i,e, stream started 2 minutes ago.
Initially the twitch polling frequency was set to 1 minute, but logs have never indicated a minute difference of < 1, which leads to believe that its not until streams are live for 1minute before the timestamp is received.
This is problematic as if we are polling at 60 second intervals, we need to ensure that we're using a threshold thats relevant enough, consider if were checking the endpoint every minute, we cant have the threshold < 1minute as the API does not seem to return values for that period, so at best it much be > 1 but < 2.
If polling at a threshold of < 3 this breaks as a value can log at say 1.1 & 2.1 and thus the entry will be posted twice (an internal caching system could prevent this).
Initally trying out at a fix of an adjusted threshold of 3 minutes with the polling frequency set to the same - will review logs to see if this fixes the issue. It will lead to delayed going live notifications, so will have to be tightened up, but it seems the 1-2 minute threshold is problematic with the minute differential.
The text was updated successfully, but these errors were encountered:
Noticed bugged out for Aoedi posting 3 times in a row - potentially an issue of running locally at same time - keep an eye on it. Generally seems to post more frequently. 👁️
Checking if minutesAgoStarted < 3 @ threshold of 2 minutes (was 3 minutes previously)
This was broken for streams that started within the 0-60second range due to API not exposing data for channels live less than a minute ago. Example:
With 3 minute polling interval (3 minute threshold):
R1. Twitch Polling starts -> channel has been live for 20seconds not exposed via API.
R2. Twitch Polling starts -> channel has been live for 3.20second now > threshold.
With 2 minute polling interval (3 minute threshold):
R1. Twitch Polling starts -> channel has been live for 20 seconds not exposed via API.
R2. Twitch Polling strats -> channel has been live for 2.20 now < threshold -> message sent.
R3. Twitch Polling starts -> channel has been live for 4.20 > threshold
There may be side effects of this variation of the 1minute but will see...
The getStreams endpoint used for getting the time a streamer went live has some inconsistencies - tbd if this is on the API end or the logic currently on the API.
This endpoint returns a UTC timestamp
started_at
which is comapred against a Date.now() timestamp, and logic is in place to get the differential in minutes i,e, stream started 2 minutes ago.Initially the twitch polling frequency was set to 1 minute, but logs have never indicated a minute difference of < 1, which leads to believe that its not until streams are live for 1minute before the timestamp is received.
This is problematic as if we are polling at 60 second intervals, we need to ensure that we're using a threshold thats relevant enough, consider if were checking the endpoint every minute, we cant have the threshold < 1minute as the API does not seem to return values for that period, so at best it much be > 1 but < 2.
If polling at a threshold of < 3 this breaks as a value can log at say 1.1 & 2.1 and thus the entry will be posted twice (an internal caching system could prevent this).
Initally trying out at a fix of an adjusted threshold of 3 minutes with the polling frequency set to the same - will review logs to see if this fixes the issue. It will lead to delayed going live notifications, so will have to be tightened up, but it seems the 1-2 minute threshold is problematic with the minute differential.
The text was updated successfully, but these errors were encountered: