Api.twitch.tv/kraken/streams/ endpoint unstable

Hi,

i come forward with this issue as i am building an app using the twitch api in certain intervals.
Kraken Streams Endpoint returns null if offline but as it seems this is happening also when the stream is online/live. i saw this issue also on twitch.tv with an offline overlay poping up and the stream going offline but after refresh the stream was still online.

is this a known issue or am i experiencing any rate limits?

My guess is that you’re encountering a cached value when calling that API. Rate limiting isn’t likely unless you’re checking for updates very frequently.

A cached value (stream array) would be fine but the cached value “NULL” makes absolutely no sense cached when the stream is really online but the api says it’s offline.
This is happening for multiple channels at the same time for like 5-10 mins every 2-3hours during which we do frequent api calls for each channel until the problem occures.

I have logs to proof the reoccuring problem if you like any further information as i am also interested in solving this issue.

A cached value of null makes perfect sense, because people rarely go live minute to minute if you’re scanning the api.

One thing that would be nice is a better cache invalidation event that handles that type of update, but generally speaking a blanket cache is always useful in reducing server load, regardless of the type of result you as the end user got.

Thx for clearing this up but i meant it makes no sense to cache a value NULL but the stream is online and was live 2hours before and 2hours after the occuring “offline” event without any change of “created_at” so the stream really was never offline but the api says it was for several minutes.
Caching makes always sense, yes, but it makes absolutely no sense if the data behind the cache is not perfectly valid.

Another example why caching is not a explanation for this issue:
If you call kraken/streams endpoint every 5s the viewer count always changes if there were changes of viewers on the stream, so i don’t think all the data is cached in that endpoint anyways so why cache it when its “NULL”.

Maybe cache is a problem here for extending the offline-but-online-period but its not the original source of this issue.

Keep in mind twitch api tends to go belly up frequently, if the created_at didn’t change it means the user never officially went offline, so they had a steady stream to the ingest server. The streams api goes offline (and if you go to the website during that time, normally all channels appear offline on the site - the crash tends to go hand in hand)

What that would look like is

Go live------|API Crash|------|Api Recovery|----

One way to help combat this, is when you’re checking live activity to record the created_at for the stream. Associate all records with the same created_at with the same stream. Also take a record of the current timestamp, this will let you measure how long the stream has been live, and how long the api may have been down. (If you don’t care about that, measure between the two recorded dates to find out the delta time of A…B)

You can assume the channel went offline if they show null for a period of minutes (5…10) - but you can go back and correct the offline record if you get another online event for the same stream after the offline event.

Thx for the fast response again.

I have exactly done this (using created_at) anyways to bypass any api hickups in the first place when writing this application.
I am also caching the twitch api data per channel to minify my api calls too.

But i see rising api call counts in my application if this error occures as it makes absolutely no sense to cache any value of NULL in my realtime-online-offline application, so until valid data is coming in i have to call the api way more frequently until i can cache first valid data (!=NULL).

I know such big systems can have hickups, my systems have hickups too, but having these hickups every ~3hrs makes on/offline stating very difficult and unreliable and as you can see it’s also happening on twitch.tv itself, which directly impacts user experience. (shown offline but really online)

EDIT:
my app has the purpose that its only “working” while streamer is really online with his stream so i rely very hard on this part of twitch api :stuck_out_tongue:

If you’re seeing it as frequently as every 3 hours, the issue is on your side. Twitch server outages are more on the scale of once for (x) minutes every few weeks. The single exception is the chatters endpoint, which 500 errors something like 3/5 times.

So you should go back to manual checking, record the endpoint you’re requesting and run the query yourself. Ensure you’re passing a client id since that’s being enforced now. If you keep having problems, try from a different ip, and make sure your dns is resolving properly.

I excluded this possibility in the firstplace by using https://www.hurl.it/ and several other REST api clients to test if it’s only me or my server which cant contact twitch but also on these independent clients the api result is the same. And as i stated above its also happening on twitch.tv so i don’t see your point moving away from the real issue here.

I have logs of march and mai showing it happens in several timeintervals (not exactly every 3hrs, sometimes twice per hour, sometimes after 6hrs ), i can provide that information with discretion.

I can’t explain every detail here. I have opened this issue not to discuss my senior development skills but to solve a problem which is definetly twitch-sided as it takes place for all clients calling the same endpoint at the same time with different IPs.

I am also using client-id in every request to minimize risk of ratelimits.

Sorry, going to have to disagree with you on this one. I track live streams all day every day, and there’s been no outages for channels barring a few minutes a few days ago, specifically at 4:57pm CST.

I’m not going to go out of my way to disprove you, but you should look at your code again. If you provide the broadcasters name I can pull the timestamps that I’ve seen them online.

Don’t get it, i just stated when this happens on my platform its also happeing on twitch.tv and on every other REST API Client, and you still say the fault is in my application? The pure raw JSON output of a rest client call cant lie, you should know that using this forums.

I am currently only checking german stream-status maybe thats the difference?

Any words from twitch staff? @DallasNChains we had a good start :wink:

UTC timestamps when it happened today:
2016-05-26 06:29:49
2016-05-26 06:32:29
2016-05-26 06:36:27
from 2016-05-26 12:57:01 switch on/off in unregular interval until 2016-05-26 13:56:51

checking the same channels manually around these timestamps with other clients than my own application got the same result

Without providing a person to test against, I can’t provide you any information to compare against.

ok check twitch.tv/betz0r for the next 24hours via kraken/streams/betz0r every 15s.

Let’s see if your application has the same bugs as mine? :stuck_out_tongue:

– Removed

– Removed

I have a bot that queries the Kraken for Twitch stream status every 30 seconds, unless it detects an issue, then it cools down before querying again as it assumes that there are network issues. As the Twitch Staff says, it takes about 3-4 minutes before I go-live and Kraken says that I have gone live. That is the caching.

I looked over my logs for the past few days, and have not seen any issues with querying Kraken at all. In the past though, I have seen users of my bot overseas (I am in the US) have occasional timeout issues and connection issues with Kraken and TMI while at the same time, I have not. Also, another user in a very busy data center in the US sometimes has issues when I do not.

Just my two cents and observations.

What @IllusionaryOne says makes absolute sense as i discussed with @tournymasterbotCurse in private and my server is based in germany - oversea - kraken.

Kraken’s response is stream:null regardless its offline or the request timed out. Maybe we can get different reponses for offline “null” and for timeout “false”? That would make a huge difference as we can distinguish the reaction.

Another dirty solution is to move my server or at least api related parts to US. @IllusionaryOne any US datacenter recommended for having no timeout problems with kraken?

Seeing as most of twitch api is on AWS now, you’d probably be good to go with AWS oregon region, since that’s probably home base - but AWS east is probably fine too, if you want lower ping to the rest of the world. (Maybe that’s home base for twitch for the same reason? Dunno. would have to dig into which region they are using).

I will try migrating to AWS for api related parts and check if the problem goes away.

EDIT: Reminder for twitch staff, this does not solve mentioned problems on twitch.tv where channel live status and viewers are provided by clientside api calls which can indeed timeout and lead to the same bad experience.

My VPS is ran from a Dallas, TX datacenter, I figured it was right in the middle of the United States (more or less) and had a pretty good chance of having decent response times to either AWS east or west in case of failover.

A silly question, you say it experiences time out issues, are you catching that exception and treating it accordingly and ignoring anything that comes back from Twitch at that point? That is what I do at least.