Hi!
the endpoint:
https://api.twitch.tv/helix/chat/chatters
seems to be extremely slow at recognizing new people joining chat, and slow at removing them from the list when they leave. IIRC the old endpoint was far superior although it was undocumented.
I’ve had a few people complain to me about not detecting viewers in chat.
example: https://api.twitch.tv/helix/chat/chatters?first=1000&broadcaster_id=73101896&moderator_id=73101896
Is there any way to improve the timing and accuracy?
In my experience it seems fine to me.
A spot test I showed up in a channel on the 3rd check, where I’m checking every minute.
Seems speedy enough to me/in line with helix operations.
after migrating to the new endpoint I’ve fielded no reports on for this across a handful of channels that I operate usage of this endpoint (usually for the purpose of currency systems)
So your testing was that it took 3 minutes, but that seems speedy enough to you. Surely you can understand that 3 minutes is unacceptably slow for various use cases? So saying it seems fine to you is kind of silly.
Why would you ever need to do something that isn’t exactly my use case?
Not if Twitch doesn’t fix it, but I think it’s far more likely that things will continue to get worse, rather than better.
User didn’t describe the speed they were getting to quntify why it wasn’t acceptable to them.
They just stated it was slow and didn’t describe why.
And off hand I don’t recal if the old endpoint was quicker than what helix is, but I suspect it was around about the same time wise.
Additionally I suspect the new endpoint relies on the same internal service as the old endpoint, so there shouldn’t be a difference in quality/speed.
So in summary: I shared the times I observed, to compare to what OP observed (which they didn’t state what they observed) and shared this forum post in the TwitchDev Developer Discord to seek other opinions.
So what is extremely slow defined as?
If you need more responsive data, perhaps create a UserVoice with your use case for needing the data faster than has always been available, as even the previous endpoint has slow responsiveness and varied greatly so 3 minutes is about par for the course for this data.
IIRC, the old endpoint would typically show a new user within 30 seconds but it varied a lot and wasn’t reliable.
I suspect you are right about it being internally the same data, so I suspect it is no more reliable. But there are various reasons why update latency could change, such as changes to the caching.
mu. Even if you are asking rhetorically, that hints at a major misunderstanding. I hope this is perfectly clear: “slow” and “speedy enough” are subjective: they vary from case to case.
That is why responding “[3 minutes] seems fine to me” is unhelpful.
Not really, but it’s moot anyway. Twitch has ignored requests for more accurate and timely information for years and has been making what is available less useful. They do not care about others’ use cases.
IIRC the old endpoint was far superior although it was undocumented.
They use the same datasource; there should be no difference in update speed.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.