Starting today, November 29, 2022, the Get Channel Information Twitch API endpoint has been updated to return 0 for the value of stream delayunless a user access token is used for the request and the user id associated with that access token matches the broadcaster_id query parameter in the request (i.e. the request comes from the broadcaster).
Why are we making these changes?
Stream delay is a feature available for Twitch Partners to increase the time from when Twitch receives a broadcaster’s video and when it is broadcast to their audience. This is helpful in a number of situations such as competitions to prevent stream sniping or IRL streaming to prevent sharing real-time locations. Last year, we added the delay field to Get Channel Information so that broadcasters could get and set their stream delay via the third-party application of their choice. We are making this change so that access to this data matches our original intent.
Who will be impacted by these changes and what action needs to be taken?
Any developer who currently uses an app access token or a user access token that does not match the value in the broadcaster_id query parameter will begin to receive “0” for the delay response field. To receive the value set by a Partnered broadcaster (which may still be 0), the request must include a user access token for authentication with a user_id that matches the value in broadcaster_id.
How does removing information match the original intent of providing that information to a specific user? Why even provide the field if it’s effectively unavailable? Why lie about the value instead of providing, e.g., null or undefined?
Normal viewers on a given stream will not be aware that the stream is delayed. This updates the API to be inline with normal/logged out viewers rather than priviledged users.
Null/undefined (or just removing the key) is a breaking change. And can cause errors in peoples applications if they don’t monitor this forum or the docs for revisions.
It’ll take time for applications (like say OBS for example) to update and they might error out/crash complete, if they don’t catch the issue of a missing expected key.
I wonder why not correct this by just showing normal the amount by which the stream they are watching is delayed deliberately, when the delay has been caused using the Twitch setting? This would make for a better viewing experience, as chat would then understand why the streamer may be interacting late.
If the streamer wants the delay to be a secret, they would set the delay buffer within their broadcast software, and the stream delay would be unknown to viewers and to Twitch.
It seems like the natural way to create a concealed delay would be for the streamer to configure this in the broadcasting client settings. OBS “Stream Delay” setting.
This also has the benefit that it is not restricted to Twitch partners. Any streamer could create a stream delay by just setting the option inside their broadcast software.
Does the Twitch “Stream Delay” feature and the ability to configure it through the API add any meaningful functionality on top of the standard Broadcast delay settings client-side “Stream Delay Setting” (within OBS) ?
Should I now believe you are so in favor of not making incompatible changes? No, because providing a completely meaningless value is an incompatible change, so that’s not consistent. But elsewhere you argued strongly in favor of incompatible, breaking changes, even going so far as to claim they aren’t really changes or breaking. What am I supposed to believe? Not 0s from Twitch, apparently.
That example doesn’t even follow. If OBS were relying on that information for some reason, it would be when the information would presumably be correct.
It is pretty standard to either exclude a key or provide a semantically defined null or undefined value. Twitch already does this elsewhere. A program that in unable to handle unexpected data gracefully is already broken. But changing 0 to null or undefined isn’t always breaking. In Javascript, for example:
In most dynamically typed languages, if there is any issue with this sort of implicit conversion, a warning will be raised instead of an error. In other languages, programmers need to be particularly careful about incoming data anyway.
I did not express an opinion on what is or is not better here. I merely answered your question.
What Twitch is doing here is the same as they did with the view_count parameter they have stopped updating it but left it in API responses. So they are being consistent here with what they have done before.
OBS was liekly a poor example here and just used as an example of “known software that uses the Twitch API”
An error/warning that might cause the program to crash or cease function leading to a confusing error presented to the user if even an error is presented at all.
Not all programmers will have setup their software to be graceful or even sanity checking incoming data.