Open sniffingpickles opened 2 months ago
Well. This is concerning. It seems like Twitch has updated the way clips are stored on thier servers. You used to be able to parse the clip thumbnail url and add .mp4 to it. This no longer works with the new static-cdn.jtvnw.net/twitch-clips-thumbnails-prod/
url's. I researched a bit to see if other devs are having the same issues. I came across this. https://twitch.uservoice.com/forums/310213-developers/suggestions/39228784-extend-clips-api-to-provide-the-mp4-url-so-editors
I will look into a workaround solution. It may be that I code it to skip/ignore clips that have the static-cdn.jtvnw.net/twitch-clips-thumbnails-prod/
url. Older clips that use the clips-media-assets2.twitch.tv
url still work. I know this is not ideal, but it should prevent the clips player from breaking.
I added a workaround until a better solution is available. The clips player now only shows clips that do not contain static-cdn.jtvnw.net/twitch-clips-thumbnails-prod
. This will reduce the number of clips that get played but I feel like this is the only solution.
https://github.com/teklynk/twitch_api_public/commit/71ee3336e180c72ecdfd1cff09f55c6c39a84952
I added a workaround until a better solution is available. The clips player now only shows clips that do not contain
static-cdn.jtvnw.net/twitch-clips-thumbnails-prod
. This will reduce the number of clips that get played but I feel like this is the only solution.
Thanks for the update, I'll see if I can dig up a workaround as well.
I have a project that look a lot like this one that stopped working since last week, looked for alternatives but all of them broke Glad to see I'm not the only one struggling with the new clips update, thanks Twitch
I was looking at a tool that a streamer friend uses called https://twitchat.fr/ For the shoutouts and clips it uses a browser source but it contains a iframe of the Twitch embed code. It's not pretty since it shows a play button, volume control... but it may be a way to get around not being able to pull the mp4 file. I have been considering a similar solution.
I was looking at a tool that a streamer friend uses called https://twitchat.fr/ For the shoutouts and clips it uses a browser source but it contains a iframe of the Twitch embed code. It's not pretty since it shows a play button, volume control... but it may be a way to get around not being able to pull the mp4 file. I have been considering a similar solution.
I was checking the iframe yesterday, but how does one detect the video load / end to queue them ? Twitch provide little to no control for clips I also check to get access to their bucket like before, unfortunately, everything is locked behind authentication tokens, all I got was 401
I was looking at a tool that a streamer friend uses called https://twitchat.fr/ For the shoutouts and clips it uses a browser source but it contains a iframe of the Twitch embed code. It's not pretty since it shows a play button, volume control... but it may be a way to get around not being able to pull the mp4 file. I have been considering a similar solution.
I was checking the iframe yesterday, but how does one detect the video load / end to queue them ? Twitch provide little to no control for clips I also check to get access to their bucket like before, unfortunately, everything is locked behind authentication tokens, all I got was 401
I am not entirely sure how the iframe solution is done. I do know that there is a clip duration value when getting the clip data from the api. One could start a javascript timer using the clips duration time and then have it switch to the next iframe src (clip) when the duration timer runs out.
I also tried grabbing the mp4 file from the new iframe/embed. It is locked down with graphql tokens that the average user does not have access to. The tokens are not part of the clips api so there is no way to reference a clip to a graphql token to build a url.
I manage to get it working using iframe and duration. The Clip API return a duration in second, you can have an iframe like this that load a clip by default
<iframe
v-if="currentClip"
:src="currentClip"
width="100%"
height="100%"
allowfullscreen
:onload="onIframeLoad"
></iframe>
When the iframe is loaded, the onIframeLoad
is triggered, inside of it, you can trigger a SetTimeout that match the clip duration, and queue the next clip.
const playNextClip = () => {
currentIndex.value += 1;
if (currentIndex.value >= shuffledClips.value.length) currentIndex.value = 0;
const slug = shuffledClips.value[currentIndex.value].clip_id;
currentClip.value = `https://clips.twitch.tv/embed?clip=${slug}&parent=${window.location.hostname}&muted=false&autoplay=true`;
};
const onIframeLoad = () => {
const clipInfo = shuffledClips.value[currentIndex.value];
setTimeout(() => {
console.log("The clip has ended playing");
playNextClip();
}, clipInfo.duration * 1000);
};
There are a lot of downside, it load the twitch interface by default, and when the clip has ended playing, it will display a grid of related clips Also, the iframe load can occur before the clip load, leading to 1-2 seconds desync. Not ideal, but it work 🤷♂️
Hmm, it appears they're updating/breaking old clips or similar. I'm having clips fail to play, but I am unable to diagnose the issue due to randomness and hosting clip player on 100+ servers.
I've noticed a lot of clips freezing so I dug a bit more into it:
Notice, thumbnail_url, and clip_url are the same, just with .mp4 after?
edit:
Looks like this is only an issue with newer clips (sub 30 days created) - maybe something in the PHP script it's querying has a new format in the API response from twitch?
edit again: I now see how the clip_url is formed, maybe something changed recently with twitch's URLs and aren't
preview-
anymorehttps://github.com/teklynk/twitch_api_public/blob/main/public/getuserclips.php#L104