[BUG] /kraken/streams responses always include vodcasts

Follow up of Streams API returns incorrect response since it was closed for inactivity reasons (why?)…

According to the v5 docs, the default (implicit) stream_type of all streams related API requests is live. However, all of these API requests also return watch_party streams (aka vodcasts), which is clearly a bug in the API and needs to be fixed. Setting a custom query param also doesn’t seem to have any effect (see the example below).

I’d also like to mention that the inconsistencies between stream_type, broadcast_platform and is_playlist are quite confusing and that they are not documented properly. To me, this looks like a not so well thought-out implementation and also doesn’t belong into the v5 API scope.

Example request of the stream_type issue (requesting Lirik’s stream, who is currently vodcasting):

$ curl \
  -s \
  -H "Accept: application/vnd.twitchtv.v5+json" \
  -H "Client-ID: ***YOUR CLIENT ID***" \
  "https://api.twitch.tv/kraken/streams/23161357?stream_type=live" \
  | jq
  "stream": {
    "_id": 25802323808,
    "game": "Batman: Arkham Knight",
    "broadcast_platform": "watch_party",
    "community_id": "5181e78f-2280-42a6-873d-758e25a7c313",
    "community_ids": [
    "viewers": 2655,
    "video_height": 720,
    "average_fps": 60,
    "delay": 0,
    "created_at": "2017-07-20T16:10:55Z",
    "is_playlist": false,
    "stream_type": "watch_party",
    "preview": {
      "small": "https://static-cdn.jtvnw.net/previews-ttv/live_user_lirik-80x45.jpg",
      "medium": "https://static-cdn.jtvnw.net/previews-ttv/live_user_lirik-320x180.jpg",
      "large": "https://static-cdn.jtvnw.net/previews-ttv/live_user_lirik-640x360.jpg",
      "template": "https://static-cdn.jtvnw.net/previews-ttv/live_user_lirik-{width}x{height}.jpg"
    "channel": {
      "mature": false,
      "status": "Next Stream: Friday @ NOON EST / 5pm GMT ",
      "broadcaster_language": "en",
      "display_name": "LIRIK",
      "game": "Batman: Arkham Knight",
      "language": "en",
      "_id": 23161357,
      "name": "lirik",
      "created_at": "2011-06-27T18:34:45.119555Z",
      "updated_at": "2017-07-20T23:35:42.892171Z",
      "partner": true,
      "logo": "https://static-cdn.jtvnw.net/jtv_user_pictures/lirik-profile_image-476e7a592cdfed74-300x300.png",
      "video_banner": "https://static-cdn.jtvnw.net/jtv_user_pictures/lirik-channel_offline_image-af3bc6ef396c76ae-1920x1080.png",
      "profile_banner": "https://static-cdn.jtvnw.net/jtv_user_pictures/lirik-profile_banner-cd63be39a747b629-480.png",
      "profile_banner_background_color": "#221f1f",
      "url": "https://www.twitch.tv/lirik",
      "views": 186859901,
      "followers": 1732908,
      "broadcaster_type": "",
      "description": "Your source for a good time, hilarity, and gaming!"

This really needs to be fixed. Writing a function to filter out vodcasts for an individual isn’t too bad. But when you are parsing lots of streams at once through loops, there is going to be that delay, no matter how slight you’ll feel it. That bugs me because I know it don’t have to be that way. I want Twitch to be fast as possible in all applications.

Seeing a reply from one of the devs would be great. The other thread also didn’t have any replies. I am wondering why…
Are you not interested in fixing this? This is clearly a bug which can easily be reproduced. If you don’t want to fix this, then the documentation is invalid and needs to be changed, although it would be a breaking change in the v5 API scope.

The issue is still present, so I’m shamelessly bumping the thread…

Bumping again, the issue is still not fixed… :frowning:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.