Hi, I’ve written an app which gathers information about current streams. I’ve noticed recently very weird examples. When I look closer to direct stream it seems like it’s id parameter changed, but streamer hadn’t created new stream because the “old” one still existed. The overall result is there are two parallel streams from one streamer and unfortunately this state lasts for a while.
I’ve checked thoroughly my code to blame it for this, but there is nothing wrong.
This weird behaviour happens rarely, most streams are saved correctly
Application refresh the streams’ data and this double parallel state still lasts(doubled stream entities have different id) so we cannot blame any non-atomic operations.
Invalid stream entities marked with red.
A stream can only have 1 id. If you’re getting a new id returned from the Get Streams endpoint then it’s because the broadcaster had established a new connection, which can happen completely automatically by most broadcasting software if there’s a momentary connection drop, or issue which caused the connection to be lost.
If you’re getting back API requests with the old ID still, it’s because all API endpoints use caching, and if you poll the excessively fast (faster than once a minute) it’s possible to hit one cache on a request and get the latest data such as a new stream ID after a connection drop, and then on the next request you may hit an old cache where it still has the previous stream ID because you were polling too fast.
Ok, thank you for your response.
What if my app calls API endpoint with slower frequency(approximately every 5 minutes)? Is there any possibility that caching might emerge in this case?
Answer may be wrong due to caching
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.