livestream - Video constantly restart
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P3, Webcompat Score:3, firefox-esr68 affected, firefox68 wontfix, firefox70 wontfix, firefox88 affected, firefox100 affected, firefox111 affected)
People
(Reporter: karlcow, Assigned: ksenia)
References
()
Details
(Keywords: webcompat:site-wait, Whiteboard: [sitewait])
User Story
platform:android impact:feature-broken configuration:general affects:all user-impact-score:30
Attachments
(4 files)
network traffic
This was reported initially on https://webcompat.com/issues/38113
With Firefox on Android,
- Go to http://www.higherground.org/watch-our-service-live/
- tap on the icon for play
- Then a second time.
Let it play.
After a couple of seconds the video restarts
John, could you help me take a look at this?
|
||
Comment 3•6 years ago
•
|
||
It seems to be a site script issue. The HLS video in the page plays when 'request desktop site' is on and when directly loading the M3U resource [1] w/o running livestream.com player script.
Karl, could you please help reach out and see if the vendor is available to check what's wrong? Thanks a lot!
|
Reporter | |
Comment 4•6 years ago
|
||
Thanks. We need to understand a bit better before contacting.
<iframe id="ls_embed_1566697245"
src="https://livestream.com/accounts/1168470/events/8793552/player?width=960&height=540&enableInfoAndActivity=true&defaultDrawer=feed&autoPlay=true&mute=false"
scrolling="no"
allowfullscreen=""
width="960"
height="540"
frameborder="0">
</iframe>
window.location = 'https://livestream.com/accounts/1168470/events/8793552/player?width=960&height=540&enableInfoAndActivity=true&defaultDrawer=feed&autoPlay=true&mute=false'
on Firefox fennec, exhibits the same issue.
It's trying 11 times then it's giving up.
https://vpe-cdn.livestream.com/playerjs/0.75.0/player.js
I was able to generate this error message but not sure it's related. It could be due to my breakpoints.
08:46:10.837 Error: [$rootScope:inprog] $apply already in progress
https://errors.angularjs.org/1.7.7/$rootScope/inprog?p0=%24apply event_embed.js:135:4548
i event_embed.js:135
h event_embed.js:137
$digest event_embed.js:137
$apply event_embed.js:137
o event_embed.js:151
it event_embed.js:135
n event_embed.js:135
onEvent eval:760
proxy eval:728
enter event-loop.js:116
enter self-hosted:1001
_pushThreadPause thread.js:222
_pauseAndRespond thread.js:593
hit breakpoint.js:259
m player.js:20524
value player.js:24946
canPlay player.js:19278
detectSupportedPlayback event_embed.js:156
togglePlayerState event_embed.js:147
stateChangeActions event_embed.js:147
t event_embed.js:147
n event_embed.js:156
closeForm event_embed.js:156
closeOpenModal event_embed.js:147
closePostVideoDetailBox event_embed.js:149
fn event_embed.js line 139 > Function:4
r event_embed.js:138
$eval event_embed.js:137
$apply event_embed.js:137
compile event_embed.js:138
it event_embed.js:135
n event_embed.js:135
|
|
Reporter | |
Comment 5•6 years ago
|
||
Maybe this is related https://github.com/angular/angular.js/wiki/Dev-Guide%3A-When-to-use-%24scope.%24apply()
|
|
Reporter | |
Comment 6•6 years ago
|
||
I have started contacting here.
https://github.com/webcompat/web-bugs/issues/38113#issuecomment-524676349
Thanks John
|
|
Reporter | |
Updated•6 years ago
|
|
||
Comment 7•6 years ago
|
||
Fenix bug for cricbuzz.com video restarting after playing 10 seconds:
|
||
Updated•6 years ago
|
|
||
Comment 9•5 years ago
|
||
The original bug on higherground has been closed on the webcompat side, they moved live streaming to Facebook.
But the m.cricbuzz.com bug still reproduces for me in Fenix nightly. But when requesting desktop site it plays fine.
I see in the network panel it is also using livestream.com, which is owned by Vimeo. We have contacts there.
https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e582331_cd91ff10cfbeacf2110e0cebc6f6fdf33b9cbff3
Karl or John, do you think this is also related to the page itself or should we go directly to livestream with this bug?
The site is ranked 24 in India and 300 globally by Alexa.
|
|
Reporter | |
Comment 10•5 years ago
|
||
(In reply to Adam Stevenson [:adamopenweb] from comment #9)
But the m.cricbuzz.com bug still reproduces for me in Fenix nightly. But when requesting desktop site it plays fine.
On rdm desktop (macos) with firefox android ua, this is working. The video plays without issues.
but indeed on the device itself it repeats.
if you let it play (on repeat) long enough, it eventually bails out.
with: Invalid URI. Load of media resource failed.
See the screenshot which shows the traffic from the moment we tap the play button to the moment it fails.
|
|
Reporter | |
Comment 11•5 years ago
|
||
first request
HTTP/2 206 Partial Content
server: openresty
content-type: application/vnd.apple.mpegurl; charset=utf-8
x-powered-by: Express
x-ls-infinite-cache: 1
x-ls-api-account: 26005112
x-ls-api-event: 8697501
cache-control: max-age=0
content-range: bytes 0-993/994
date: Fri, 28 Feb 2020 00:54:26 GMT
x-served-by: cache-tyo19947-TYO
x-cache: MISS, MISS
x-cache-hits: 0
x-timer: S1582851266.717006,VS0,VE640
age: 0
via: 1.1 varnish
accept-ranges: bytes
content-length: 994
X-Firefox-Spdy: h2
last request
HTTP/2 206 Partial Content
server: openresty
content-type: application/vnd.apple.mpegurl; charset=utf-8
x-powered-by: Express
x-ls-infinite-cache: 1
x-ls-api-account: 26005112
x-ls-api-event: 8697501
cache-control: max-age=0
content-range: bytes 0-993/994
date: Fri, 28 Feb 2020 00:55:49 GMT
x-served-by: cache-tyo19947-TYO
x-cache: HIT, MISS
x-cache-hits: 0
x-timer: S1582851349.249011,VS0,VE158
age: 0
via: 1.1 varnish
accept-ranges: bytes
content-length: 994
X-Firefox-Spdy: h2
|
|
Reporter | |
Comment 12•5 years ago
|
||
<div ls-vod-player="" data-flash-container="postVideoContent" data-is-embed="true" data-player-name="'video_post'" data-video-id="selectedFeedData.data.id" data-is-video-embed="isVideoEmbed" class="ng-isolate-scope">
<div class="player_wrapper js-vod_player_wrapper" id="postVideoPlayerContainer">
<div class="player_inner" id="js-vod_player_inner" ng-show="readyForEmbed" style="width: 100%; height: 100%;">
<!-- ngIf: playbackType === 'flash' -->
<!-- ngIf: playbackType === 'pjs' -->
<!-- ngIf: playbackType === 'mjs' -->
<div class="playerm_player_wrapper js-playerm_playback ng-scope" ng-if="playbackType === 'mjs'" ng-init="initializePlayerM()" style="">
<div class="mjs-root-view">
<div class="mjs-video-view">
<video class="mjs-video-element" poster="http://img.new.livestream.com/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_630.jpg" src="https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e586d49_35e893588e5c49805c9fc70e8db7207515d84842"
controls=""></video>
</div>
<div class="mjs-spinner-view" style="display: block;">
<div class="mjs-spinner-view__donut"></div>
</div>
<div class="mjs-ad-view" style="display: none;"></div>
<div class="mjs-hit-view" style="display: none;">
<div class="mjs-hit-view__play-icon">
<div class="mjs-hit-view__arrow"></div>
</div>
</div>
</div>
</div>
<!-- end ngIf: playbackType === 'mjs' -->
<!-- ngIf: playbackType === null -->
</div>
</div>
</div>
The spinner is here each time it tries to replay the video.
the video is inserted in the page through
<iframe id="video_player_193757381"
src="https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&height=300&enableInfoAndActivity=true&defaultDrawer=&autoPlay=true&mute=false"
scrolling="no"
allowfullscreen=""
width="100%"
height="100%"
frameborder="0"></iframe>
Let's try to load directly
https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&height=300&enableInfoAndActivity=true&defaultDrawer=&autoPlay=true&mute=false
The same thing is happening. so we know this is not cricbuzz issue.
There is a very very very brief moment when we start the video which is i believe is the icon of the unsupported format.
so maybe they are sending the wrong type.
<video class="mjs-video-element"
poster="http://img.new.livestream.com/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_630.jpg"
src="https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e586d49_35e893588e5c49805c9fc70e8db7207515d84842"
controls=""></video>
so yes adam we can contact directly livestream.
|
|
||
Comment 13•5 years ago
|
||
Contacting Vimeo by mailing list about this.
|
|
||
Comment 14•5 years ago
|
||
Livestream says we aren't supported. We should investigate what's required to fix this in the webcompat addon.
|
||
Comment 15•5 years ago
•
|
||
This seems like a buggy server issue, perhaps. On Desktop when I request the HLS manifest, I get 200 OK. From Karl's screenshots, we're getting 206 Partial Content.
Note that the content-length is 994 for the 200, and Fenix is getting a 206 with content-range: bytes 0-993/994. So it's going back for the last byte and getting the same content again, in the meantime playing the first few frames, then repeating once it gets a new 206 (which is the same over and over).
edit: I just learned 0-993 means all 994 bytes are transferred.
John, do we have known bugs similar to this?
|
|
||
Comment 16•5 years ago
|
||
Actually, Chrome Mobile gets a similar 206 as well, and they don't end up in a reload loop.🤔
|
|
||
Comment 17•5 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #15)
Created attachment 9130894 [details]
Screen Shot 2020-03-04 at 3.07.32 PM.pngThis seems like a buggy server issue, perhaps. On Desktop when I request the HLS manifest, I get 200 OK. From Karl's screenshots, we're getting
206 Partial Content.Note that the
content-lengthis 994 for the 200, and Fenix is getting a 206 withcontent-range: bytes 0-993/994. So it's going back for the last byte and getting the same content again, in the meantime playing the first few frames, then repeating once it gets a new 206 (which is the same over and over).edit: I just learned
0-993means all 994 bytes are transferred.John, do we have known bugs similar to this?
Gecko doesn't support HLS on desktop and my guess is that their script for desktop transmuxes the cotents from HLS to MSE. If that's the case, they must run different code for desktop than mobile, where HLS is supported natively. Could the different status codes be caused by different versions of scripts?
|
|
||
Comment 18•5 years ago
|
||
BTW, the native HLS support in GV relies on Exoplayer to handle the M3U8 contents. It could be that Exoplayer doesn't support 206 responses properly.
|
|
Reporter | |
Comment 19•5 years ago
|
||
https://github.com/google/ExoPlayer/issues
John is there a way to know which version of the ExoPlayer is being used? (from the devtools console?)
Thanks
|
|
||
Comment 20•5 years ago
|
||
(In reply to Karl Dubost💡 :karlcow from comment #19)
https://github.com/google/ExoPlayer/issues
John is there a way to know which version of the ExoPlayer is being used? (from the devtools console?)
Thanks
I don't think so. But according to the commit[1], it's r2.4.0.
[1] https://hg.mozilla.org/mozreview/gecko/rev/af12643a49c4231aca96c149bc76e2cf9827ffac
|
|
Reporter | |
Comment 21•5 years ago
|
||
https://github.com/google/ExoPlayer/releases/tag/r2.4.0
is from april 27, 2017
latest is r2.11.3 february 19, 2020
around ~3 years ago.
that's a lot of things to digest.
https://github.com/google/ExoPlayer/compare/r2.4.0...r2.11.3
I see a couple of things related to hls in there, but that doesn't mean that would necessary solve this issue.
https://github.com/google/ExoPlayer/issues/2863
https://github.com/google/ExoPlayer/issues/6155
https://github.com/google/ExoPlayer/issues/6322
https://github.com/google/ExoPlayer/issues/6903
|
|
||
Comment 22•5 years ago
|
||
Are there any updates on this issue. Fenix has requested that this be resolved as a high priority.
|
|
||
Comment 23•5 years ago
|
||
My guess in comment 18 was wrong. I thought it could be some bug in ExoPlayer that causes the master playlist file [1] to be loaded repeatedly, but when trying to reproduce it today I noticed that the master playlist file [1] is shown again and again approximately every 8s in Network panel, as in comment 15. If the bug is indeed in ExoPlayer, Network panel should only show the playlist once because the following fetches will be handled by ExoPlayer internally and invisible to us. It seems to me that ExoPlayer does fetch the index playlist file [2] provided in the master playlist and play it for ~8s, then some code in the player script that triggers HTMLMediaElement.load() and causes the master playlist to be reloaded.
Adam, could you please help contact Vimeo and ask if their script does something like that? Thanks a lot!
[1] https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5ec46e2c_83259c5db1dfde0b64d9d00a2ad23148154f5771
[2] https://vod.livestream.com/5ec47c69_b7bfe91d734c145fdbefbe31e87291dbba2cf8ff/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_428.m3u8
|
|
||
Comment 24•5 years ago
|
||
Tom, given Comment #23, do you think we could work around this while we wait on outreach? I guess we still only have a theory that we're calling load() again, perhaps something you can verify?
I've just checked in with John and believe we are at the same place as comment 23 -- a site script appears to be causing us to reload the video. Any updates on outreach or if we can mitigate this elsewhere are appreciated.
|
|
Reporter | |
Comment 26•5 years ago
|
||
The site seems to have changed their livestream provider
http://www.higherground.org/hgbc-live
http://www.higherground.org/live-stream-archive
And their videos in the current archive is working.
(In reply to Adam Stevenson [:adamopenweb] from comment #13)
Contacting Vimeo by mailing list about this.
The message on Vimeo mailing-list was on March 5, 2020
I asked around, and apparently Firefox on Android is not a supported platform for Livestream.
This is still happening.
WONTFIX?
|
||
Comment 27•4 years ago
|
||
Currently there are no live streams available.
https://prnt.sc/10p3p6p
I can confirm that videos from archived work correctly without interruption.
https://prnt.sc/10p3pvc
I've also checked the video bellow and it does not play on Firefox (keeps showing a loading spinner and eventually an error), but plays on Chrome.
https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&height=300&enableInfoAndActivity=true&defaultDrawer=&autoPlay=true&mute=false
https://prnt.sc/10p3svp
https://prnt.sc/10p3s7b
Tested with:
Browser / Version: Firefox Nightly 210317 (🦎 88.0a1-20210313094300)
Operating System: Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 28•3 years ago
|
||
Using URL: https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&height=300&enableInfoAndActivity=true&defaultDrawer=&autoPlay=true&mute=false the video still keeps reloading and eventually gave an error "Video could not load or timed out"
https://prnt.sc/cRYfWsZwIEWC
Note: The video plays on Chrome.
Tested with:
Browser / Version: Firefox Nightly 100.0a1 (🦎 100.0a1-20220323094932)
Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
|
|
||
Updated•3 years ago
|
|
||
Comment 29•3 years ago
|
||
I've been investigating this on my own (in other words: forgot to search for duplicates first) and found a few things that may or may not be useful. (I also reached out to their support, and they said it was a known issue but seemingly not a priority. However, I'm not sure if this is a site issue or a Firefox issue for reasons noted below.)
From my investigation, it appears that this is the result of a script which checks if the video is actually playing, and in our case erroneously determines that it is not, so tries to restart it. Due to a combination of obfuscation and a lack of JS skill on my part I couldn't determine exactly how it does this, but it gives up after 80 seconds. (If anyone wants to look, a place to start is roughly lines 5350-5400 and 5472-5512 in m.js (Main Thread -> vpe-cdn.livestream.com -> playerm), or search for the strings "Timeout has been reached. Playback is not detected." and "Timeout. Retry attempts are expired." in that file.)
Things that fix this:
- Requesting the desktop site (it's an issue in the mobile player specifically)
- Using another browser
Things that don't fix this:
- Switching user-agent (which is far harder than it should be on mobile)
- Disabling uBlock origin
- Using a fresh profile
Things that don't reproduce this (curiously):
- Using a mobile resolution and user-agent on desktop (I think I verified that this ended up with the mobile player)
|
||
Comment 30•3 years ago
|
||
This is still an issue.
URL: https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&height=300&enableInfoAndActivity=true&defaultDrawer=&autoPlay=true&mute=false
Tested on:
Operating system: OnePlus 6 A6000 (Android 11)
Browser/Version: Firefox Nightly 111.0a1-20230207043534
|
||
Updated•1 year ago
|
|
|
Assignee | |
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
||
Updated•5 months ago
|
Description
•