Codecov Report

Merging #2692 into master will increase coverage by <.01%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master    #2692      +/-   ##
==========================================
+ Coverage   52.52%   52.52%   +<.01%     
==========================================
  Files         245      245              
  Lines       15378    15379       +1     
==========================================
+ Hits         8077     8078       +1     
  Misses       7301     7301

Btw, we still haven't cleaned up the old API stuff. I can't seem to find @back-to's PR with some of the cleaning work.

If we're removing features, we should also remove the stuff which has been unsupported / unused for a while now.

should probably make a new version 1.3.0 with this added

Btw, we still haven't cleaned up the old API stuff.

can be done, but it is not important

@bastimeyer I still really don't like the idea of using Twitch's client ID as our official stance. I'm pretty sure doing so puts us in violation of the ToS where as before we've been able to avoid doing so since we use our own key. Using their client ID is a clear case of reverse engineering the site to pull that information. I'm wondering instead if we should just modify how Streamlink works to require the user to configure this from their own account. I know it will suck but it's the only legitimate alternative I can think of.

Edit: I also still believe this is some sort of functionality issue with that API with how intermittently it seems to not work. The pattern makes it seem as though someone is fixing it who works at Twitch, last week it wasn't addressed until after the long weekend, but was working fine Tuesday morning and throughout the week. Now it failed some time on Friday, and it's still persisting today when presumably the person who fixed it before is on their weekend. It could also be (like you mentioned) that it's some sort of anti-spambot functionality they've put in place and we're being dinged by that due to the fact we have a huge amount of legitimate traffic using our key, they may be unable to see the difference with whatever filtering they have put in place.

I don't like using it either, but the sad reality is that we have to at some point if these issues keep continuing, which they clearly do. Other big applications like youtube-dl are using it as well. It doesn't justify it of course, but asking every user of Streamlink who wants to watch Twitch streams to manually change Streamlink's client-id or asking them to open their web browser's dev tools and extracting a certain header is complete nonsense.

The OAuth tokens from the website are by the way "not legitimate" either, because they are generated from Twitch's own client-id and thus are "reverse engineered" too, if you're applying the same logic here. Streamlink has always used the same private API endpoint for acquiring the stream's access token, which means that we were "reverse engineering" the website the whole time, but just telling Twitch that we're not a user of the website by sending our own client-id instead.

So what would happen if this is indeed a ToS violation? If Streamlink's cliend-id should get revoked by Twitch if they decide to go against all third party applications which are accessing streams, then regular public API requests (kraken v5) would not be possible anymore. Those API requests are only needed for optional stuff though, like retrieving the account name after authentication, which is off the table anyway, or for getting stream/video metadata, like the title, streamer name, etc. Whether they would apply legal measures, I'm not sure.

Btw, the API rejects all third party client-ids / OAuth tokens, not just Streamlink. And it's also been down during the week, not just the weekend. We simply don't know why it is happening, which makes having a decision here so difficult. All we know is that it's usually happening around 9pm CET (whatever timezone it is for them) and that it lasts for several hours or days on the weekends (second weekend now).

I'd say that we should calm down and don't rush things. It's a stupid situation, but putting us into an even more stupid position would be a bad idea.

@bastimeyer I agree that it's nonsense to ask that of users, but Twitch's lack of communication and clarity on this issue for an obvious failing in their public APIs is also nonsense. I know the OAuth tokens aren't legit either but at least in that scenario it's still being generated. The ID that we're sending as the Streamlink user was generated by their system from their dev tools and then used by us for our application so I feel like it at least has some more legitimacy even if it uses a non-public API. I didn't realize however that other apps like youtube-dl were using Twitch's key. I thought they had their own that they requested from the dev platform. That actually annoys me much more because we're basically being punished for trying to do things as properly as we can.

I know that others have been unable to use their creds as well, as you said we simply don't know why it is happening and they won't give us an answer because it's a "private" API that they make publicly available. I'm not in any rush either and am perfectly calm about it I just think we should discuss what options we have (if any to be seen that we are trying to be good "Twitch citizens" since I know they monitor this project). I'm not sure what you mean by putting us in an even more stupid position however, are you talking about pushing people to approve via the oauth? I agree that the whole situation is stupid.

I meant that by unnecessarily risking to break ToS and removing features, because it's still possible that this issue does get fixed eventually by Twitch.

Ahh okay that makes sense and I agree.

To be clear, I can understand why Twitch would want to kill Streamlink and anything based on it due in part to the way it uses their API (there is no connection pooling for example). However to understand why Twitch reacts the way it does, you have to think like a complete sociopathic moron.

Read their replies very carefully and you'll start to understand.. though anyone with half a brain knows the API is used by many applications, in their tiny heads they didn't break anything because it was considered 'private'. Randomly breaking something with increasing occurrences is literally part of the plan many developers / tech operations consider acceptable..

They claim to be run by a community of volunteers (BarryCarlyon's responses to you are sraight ignorant) -- On a site literally called "Twitch developers" none the less where supposed twitch staff post and despite being given a dubious name as a subdomain under twitch.tv.

tldr You will never "fix" this. Create an app on Twitch, any app. Use that application's client_id/whatever they require today(tm). Rather ironic thing is how much ytdl and streamlink are used internally especially before Twitch even had vods.

@bastimeyer Seems like this is going to stick around permanently now. It hasn't magically recovered for quite a few days now unlike previously. How much longer do you want to wait before we merge this?

Yes, it's pretty clear now that Twitch has made a decision and that it was not a mistake on their end (the dev forum answers were just useless non-staff answers, so waiting was justified). Let's not wait any longer and get it fixed here.

As I've said, the twitch oauth parameters will not be removed by this PR and will still be available as "placebo" parameters (except for public API calls where auth data is optional anyways).

Removing them would require a major version bump I think. We should add a note to the docs though. I'll see if I can do this later today so that we can have a new release. I'll have to update the Twitch GUI anyway today because of this.

Okay. I'm going to merge this in then, I'm sure if @beardypig had any concerns they would have weighed in with them.