On the subject of live streaming problems

UPDATE: Please fill out this form if you're having problems, any info helps!

https://docs.google.com/forms/d/15OJmcEw4DJ20osPV6zWNgB3azUKFu7ddwxBju6IcB2Q/viewform

I know that a lot of you have been having problems with the stream cutting out and the play button showing back up. So the root of this problem is Akamai is dropping your streaming connection, and telling our video player that the stream has ended.

So here's what we're doing about this, we're attacking it from two angles. Prepare for a long explanation:

1. Edgework is working with Akamai to try and solve the problem on their end. Nothing significant changed on our end to cause these problems so we're working with them to try and pin down the problems in the stream encoding and delivery process. This is the real solution and we are still working with them daily
2. I've been making some changes to our video player to try and recover from these issues. Basically, when the player gets a signal that the stream has ended we don't believe it, we immediately try to recover the stream and resume it. We then wait a couple seconds to see if the stream recovered properly, if not we end the stream and the play button comes back up. This fix is live and is actually why some people are seeing the stream stop but the audio continue in the background. What's happening here is the stream is recovering but we're not waiting long enough to see if it recovered properly. I'm working on tweaking the time so by the next live stream hopefully this stream recovery will work properly. We're really close to getting this right, I can feel it!

I want to thank you and all the engineers for working so hard on an issue that is caused by the provider and not on the GB side. I know its super frustrating for everyone at GB since there's very little that can be done that's not on the Akamai side. I remember these issues happening a few years ago (possibly with the same provider?) and hope that it all gets resolved in the end. Until then, I will continue to press (re)play!

Cool, thanks for the update!

I'll reflect what AlwaysBeClothing said.

You guys are the real heroes of Giant Bomb. Thanks very much for your efforts.

Thanks for the update. One thing I have noticed is it happens way way less on GB East streams. I'm in the UK so I was wondering if the distance was a factor?

Anyway good luck getting to the bottom of it and thanks for keeping us updated.

EDIT: Filled in the form.

Thanks for all your work! The play button coming up to restart the stream is a really nice compromise for a problem that isn't your fault, nice one :)

Sweet thanks for letting us now! Just ran into this. Happened a few times for about 10 mins then normalized again, not a huge deal.

Thanks for the transparency and hard work duders!

Good stuff. Thanks for the update!

Keep up the good work!

Thanks for all the hard work!

As someone who is having communication issues with the IT department at work, I very much appreciate you guys explaining what is going on and what you're doing to fix it! Keep up the good work!

Filled out the form posted, hope it helps! I really appreciate all the hard work ya'll do. Thanks!!! =)

Double thumbs up

I ran into the Issue onces a couple of UPFs ago, before I realised that anyone else was having the problem. I thought that it may be my internet connection not downloading the video fast enough and cutting it out, so I scrubbed back a few seconds (so i was watching Live - 5 seconds), thinking it would give my pc some buffer time. It seemed to fix the issue for me.

You guys are doing gods work trying to fix this issue though, especially considering it seems to be the fault of a third party and you guys have been taking the flack for it. You're appreciated!

I've made an arsehole thread elsewhere, but the effort is really appreciated.

Going back a few seconds works for me as well

I filled out the form, but decided to post the same thing here, hoping it can help others (I did not have problems with the stream cutting out, I simply could not watch it at all.):

I could not play any video or livestreams on the site for a while (except for streaming off download links) and I just managed to fix it. I opened the Developer Console and saw a insecure connection blocked error for "https://fast.cbsi.demdex.net/dest4.html?d_nsid=0" (apparently the SSL certificate does not match the site's url). I use a browser addon called "HTTPS Everywhere" that tries to force HTTPS connections on websites that use both HTTPS and HTTP. I clicked the HTTPS Everywhere icon in Google Chrome's toolbar and unchecked "Giant Bomb.com (partial)". That fixed it. I'm now able to watch videos and livestreams using the flash player. You guys probably should get in touch with the developers of HTTP Everywhere, so they can fix it. I think there are other privacy-oriented addons like Ghostery and Disconnect that do the same thing, but I haven't tested them to see if they also break videos on Giant Bomb.

Workaround found for Chrome, at least for me:

1.) Open a tab and go to: chrome://flags/#disable-accelerated-video-decode
2.) Click the "Enable" text link which will actually disable hardware video acceleration
3.) Close Chrome completely then re-open and start watching the stream again.

@doctorkohaku: As far as HTTPS Everywhere is concerned, we are not able to serve 100% of our content over HTTPS as some of our third party components do not support secure protocols. It sucks, because it would be really nice, but some of the options are out of our hands, as they are business decisions out of control from us engineers. I'd really like to be able to serve everything over S.

Keep up the good work!

@jslack: My understanding of it is that it does not simply try connecting to every site over HTTPS - it uses an external rule list (similar to ad-blocking addons or HSTS Preload) to determine which sites/urls work fine over both HTTP and HTTPS. fast.cbsi.demdex.net appears to be on that rule list, so the addon forces a HTTPS connection even though the SSL certificate is invalid, causing AJAX requests to fail with a security exception.

I reported this problem to the developers of HTTPS Everywhere and you can follow the bug report here: https://github.com/EFForg/https-everywhere/issues/3084

And here's their ruleset for Giant Bomb: https://github.com/EFForg/https-everywhere/blob/stable/src/chrome/content/rules/Giant_Bomb.com.xml

@doctorkohaku: Ya, I'm submitting a PR against it. Last time I looked at it, it wasn't possible due to mixed content coming from different scripts, that we now self host.