-
-
Save odensc/764900d841cbdd8aa400796001e189f1 to your computer and use it in GitHub Desktop.
| /// twitch-videoad.js | |
| const origFetch = window.fetch; | |
| window.fetch = (url, init, ...args) => { | |
| if (typeof url === "string") { | |
| if (url.includes("/access_token")) { | |
| // url = url.replace("player_type=site", "player_type=site"); | |
| } else if ( | |
| url.includes("/gql") && | |
| init && | |
| typeof init.body === "string" && | |
| init.body.includes("PlaybackAccessToken") | |
| ) { | |
| // const newBody = JSON.parse(init.body); | |
| // newBody.variables.playerType = "site"; | |
| // init.body = JSON.stringify(newBody); | |
| } | |
| } | |
| return origFetch(url, init, ...args); | |
| }; |
Extension/tampermonkey script (if what @Brybry said is true) will probably be needed soon. Twitch is now getting feisty and doing things like limiting to 480p to annoy people into disabling uBlock. Found another player_type but it won't last long obviously.
The recent update to reset the playertype to a "non resolution capped one" having the funny side effect of "player_type=site" apparently now being used everywhere, greeting users with up to 90 seconds of pre-rolls at the frontpage.
That the frontpage still works for non uBO users while "player_type=frontpage" as we used it a few days before got fixed by Twitch, it should be clear that there is atleast one ingredient on the formular we are missing out on. Origin might be already a good start.
I've been using the script @pixeltris posted here a couple of days ago (https://gist.github.com/pixeltris/77c676ef65b0b76e7aa56d8a0e0b3897), without any problems like forced low resolution or ads, it's been working fine for me and when ads are played (both preroll and midroll), its replaced by the PIP feed (that is 480p though), but I have not once seen an ad since I changed to that script.
@PureFallen thanks for that note, I just completely commented it out for now. Also, they locked the frontpage player_type so it only blocks ads on streams that are actually featured on the frontpage.
Doesn't greasemonkey/tampermonkey's
GM_xmlhttpRequestallow modifying theOriginheader?So in the fetch hook do a XHR on
video-weaver.xxx.xxx.ttvnw.netm3u8 requests instead. I'm just not sure on implementation for wrapping GM_XHR and properly emulating fetch API behavior with a Response promise.