1303105 - Couldn't stream more than 10 seconds today's live stream

Status: RESOLVED INVALID

(Webtools Graveyard :: Air Mozilla, defect)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

I had plenty of errors in the developers console, both HTTP errors (code 409 or something?) and also a red error message. Sorry I didn't note these down, but the result of this was that the video streaming stopped after ~10 seconds and never recovered. The only way to keep on watching the stream was to reload the page every 10 seconds, losing a few seconds of content every time. As a result, I have used another browser to watch the live stream, on which it worked fine :(.

Tentatively classifying as AirMo streaming issues (I could not reproduce with a recorded video on airmo), but since another browser worked well, it might actually be a bug in firefox. (I was using today's nightly) 

:emorley said he saw the same thing (and maybe has more logging? :)).

If you have a constant live stream I could try, maybe I could give a more useful description of the errors I saw in the console.

Comment 1

[Peter Bengtsson [:peterbe]]

Not sure what the 409 error is about. 

One thing that does stumble a lot of people is if you have third-party cookies disabled. When you start the stream and it's a private even you to able to have a cookie with the wowza CDN. 

Can you try https://air.mozilla.org/browser-test-stream/

Thanks for your patience and bug report!

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Thank you for the answer! I could reproduce, and it was actually a 403 error on the akamaihd domain, indeed caused by one addon [1] I'm using that destructs 3rd party cookies (and much more). White-listing akamaihd.net fixed it for me, and I can now watch the stream without any pause! Thanks!

Is there any way that after a few 403 errors, the client could detect there's something wrong and show a message to the user asking to enable third party cookies? It would greatly enhance the UX, since as of today, users may think there's something wrong with their Internet connection, or that the streaming is under heavy load, or something unrelated.

[1] https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies

Comment 3

[Peter Bengtsson [:peterbe]]

I'm investigating if there's a way to hook into the error handling of hls.js to see if it's possible to get clues like that. If it's possible and the error appears to be a 403 Forbidden we could potentially display a div that says "Having problems? Check that you don't have third-party cookie blockers for akamainhd.net" with links and stuff.

Comment 4

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2016-09-20 at 8.47.15 AM.png

I managed to "reproduce" it at least. Now I just need to figure out how to hook into that error handling.

Comment 5

[Peter Bengtsson [:peterbe]]

Seems hls.js doesn't tigger on this
https://github.com/dailymotion/hls.js/issues/491#issuecomment-233289864

Comment 6

[Peter Bengtsson [:peterbe]]

Attachment: clappr-hls-template.html

Richard, 
This is the magic sauce. 
This is the Clappr HLS template I used in my testing locally. 
Because our Video templates contain the secret key used to generate a temporary Akamai token, I've taken the HTML I used and replaced the key with "KEY_GOES_HERE" (remember to put quotes in when you replace with the *actual* key)

Comment 7

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2016-09-20 at 11.51.00 AM.png

What I had to do to make the HLS stream work when disabling third-party cookies.

Comment 8

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2016-09-20 at 11.53.08 AM.png

What the warning looks like.

Comment 9

[Peter Bengtsson [:peterbe]]

Richard, 
This is really exciting!!

So it turns out that the network error handling is not propagated to the player (i.e. Clappr). See https://github.com/dailymotion/hls.js/issues/491#issuecomment-226532875

Because of that, there's no way to configure Clappr such that you can investigate any errors and see if the reason it errored was because of a 403 Forbidden.

So, instead I wrote my own. 

The way the HLS works, for private events, is that it first loads `https://akamai/venue/playlist.m3u8?secrets=secrets` then once that's done it just loads `https://akamai/venue_p720/chunklist.m3u8` (note that it no longer has the "?secrets=secrets" query string henceforth. 

So, what I did was that I simulated the very same thing with two plain AJAX queries using jQuery. Then I get great control over the error handling on that second URL (the chunklist) and I can use that to see if the error was 403. If so, I display a neat little warning message over the video and explain which site you need to add to your third-party cookies white list. 

I've tested this quite extensively on my laptop version. 

Your job now, if you chose to accept it, is to try to apply this on dev, stage and prod. (I'm happy to help but I want your engagement and opportunity to correct and test fully). See the attached template code here in comment #6.

See what it looks like in comment #8. 

This is going to make the experience A LOT better for people with destructive or prohibitive cookie behaviors trying watch the private live streams.

Comment 10

[Andy Kochendorfer]

Platform deprecated.