Have you searched for similar issues? Yes
Description
No streams play on Twitch, with shields up or down.
Brave: 0.23.11
V8: 6.7.288.46
rev: 6565c0689f8bfbd6f4d03e2e8c68c9381da157f6
Muon: 7.1.0
OS Release: 17.6.0
Update Channel: Beta
OS Architecture: x64
OS Platform: macOS
Node.js: 7.9.0
Brave Sync: v1.4.2
libchromiumcontent: 67.0.3396.87
Reproducible on current live release:
No
Additional Information
Thought it was because fingerprinting protection was on. But even with that off, streams still don't play.
I'm encountering the same problem on macOS 10.13.5 beta.
Brave: 0.22.810
V8: 6.7.288.43
rev: 8f30eeba0c2d6cccf1920a360b4774f820adbc58
Muon: 7.0.6
OS Release: 17.6.0
Update Channel: Release
OS Architecture: x64
OS Platform: macOS
Node.js: 7.9.0
Brave Sync: v1.4.2
libchromiumcontent: 67.0.3396.71
Initially thought this might be similar to https://github.com/brave/browser-laptop/issues/12398 however, this has also been reported on twitter several times recently. One twitter user had this clear up on its own, with no action from them. Another user said if they open a new session tab then this works fine.
Internal report of issue: @alexwykoff
Twitter report of issue (release version, not beta):
https://twitter.com/pincho_gaming/status/1007521644078944256
https://twitter.com/stevemumford/status/1009700410024775680
https://twitter.com/Jii_El/status/1009818453052665856
same. Twitch.tv has been broken again recently.
macOS High Sierra v10.13.5 (17F77)
Brave | 0.22.810
-- | --
V8 | 6.7.288.43
rev | 8f30eeb
Muon | 7.0.6
OS Release | 17.6.0
Update Channel | Release
OS Architecture | x64
OS Platform | macOS
Node.js | 7.9.0
Brave Sync | v1.4.2
libchromiumcontent | 67.0.3396.71
Some forum posts are referencing this issue: https://github.com/brave/browser-laptop/issues/14422
I also ran into this today with:
Brave: 0.22.810
V8: 6.7.288.43
rev: 8f30eeba0c2d6cccf1920a360b4774f820adbc58
Muon: 7.0.6
OS Release: 10.0.17134
Update Channel: Release
OS Architecture: x64
OS Platform: Microsoft Windows
Node.js: 7.9.0
Brave Sync: v1.4.2
libchromiumcontent: 67.0.3396.71
On a fresh profile, this is what I see when visiting twitch.tv/sanchowest:
Upon dropping shields, the pre-roll ad plays but nothing else:
Here is the console output for Chrome, where the stream appears to be working:
The issue exists when testing Muon alone, in the absence of any browser-laptop code on top. In the following GIF, I opened the browser-laptop-bootstrap/src/out/Release
directory and ran brave.exe
. By default, this shows the initial Electron demo page. By pressing Ctrl+Shift+I I opened the webview's dev tools, and proceeded to change the page's location:
Marked this as release/blocking
as we're getting more and more reports. As Twitch is a major component of Brave Payments, we need to figure out what is going on here. We can discuss if it's blocking during our weekly desktop triage meeting.
+1 from Twitter https://twitter.com/YanYears/status/1011256251823427584
Ditto this issue.
I've tried current builds (Tor tabs), 0.24.x, and master - all fail when trying to load twitch content (shields up or down, doesn't matter). Looking more into this
Looks like this error (seen via console) may be related:
player.js:28 Uncaught (in promise) Error: Experiment
b8d1e7be-59f7-4ee3-a0c6-54ce94366d14
is deprecated
at player.js:28
This appears to be the experiment in question:
https://github.com/CommanderRoot/Twitch-experiments/blob/97cff1225bbfd6a1bb2b29b24d555cc684b9cf3c/experiments.json#L5685
(this repo is tracking changes made to https://www.twitch.tv/experiments.json)
However, I don't think this is related as Chrome gets this error logged to the console too
Looks like the problem is that the player is trying to initialize the Chrome Cast APIs (window.chrome.cast) and (because that functionality isn't present), it's failing. Looking for a work-around...
Found a fix! 馃槃 PR coming
I thought I had a fix- but it seems that this problem is intermittent. The "fix" I had didn't actually work, I just got lucky.
The best guess I have is that whatever is breaking may be a Twitch "experiment". You can verify this intermittent behavior by deleting your profile, relaunching Brave, and visiting twitch again. Sometimes it works, sometimes it doesn't
I have gotten rid of the Chromecast errors... but the streams still consistently fail for me. I've been comparing the headers between Brave, Firefox, and Chrome and haven't made any good discoveries (yet). This definitely needs more investigation
@bsclifton So you suggest testing with a new profile to see if the problem goes away?
@Tomatoshadow2 no- definitely not. Just noting something that @kjozwiak and myself noticed while troubleshooting. At this time, there isn't a work-around available and we're still looking into it 鈽癸笍
@bsclifton Ok, thanks, appreciate it, I just wanted to be sure I didn't miss any STR steps for you and the rest of the team.
As per @bsclifton comments here and our earlier conversation, this requires more investigation and unfortunately won't get fixed in time for this release. Moving this into 0.23.x Release 2
which will be the release after the Tor release.
+1 from community https://community.brave.com/t/twitch-streams-not-working/26385?u=eljuno
+1 from me
I noticed this issue a few days ago. Currently running 0.23.19 on Linux Mint. Glad to see it is a known issue and being worked on.
Thanks!
@chuckreynolds unfortunately, that doesn't seem to fix the issue (I updated the commit to note that it doesn't fix it - https://github.com/bsclifton/browser-laptop/commit/9a9212ceeacf4a31d241f64b672be2b18d3aa67b)
I believe the cause is that (even with shields down), Brave is being detected as an adblocker. When that is true, it's failing to download a resource that the video player binds itself to. The logic detecting if the browser has adblock enabled is trying to run fetch
against a bunch of tracking pixels / advertising content
Trying this out with Brave Core (binaries not available publicly yet), it also fails when adblocking is on. However, with shields down it does work great.
The problem is further complicated by this logic intermittently working (which is what happened when I thought I had fixed it). Apologies this is taking so long to solve- it's definitely a complex problem 鈽癸笍
(For everyone's info brave-core is available at https://github.com/brave-core -- we just do not yet publish self-updating builds but those are coming next month.)
So it sounds like Twitch is (intentionally or accidentally) fingerprinting Brave based on Muon but not Brave based on the chromium front-end (brave-core). Wow.
Should be possible to find out what is different in the DOM that could be involved. Idea: survey all property names to right of dot in the code that fails on Muon and see if different set of property names from what works on brave-core. If same, have to hunt through set to find what might be present in Muon-based DOM but not in brave-core. If diff then the delta could be the culprit.
+1 same issue, unable to resolve
also the bravecore link posted above by BrendanEich takes me to an error page
@slambert92 try this one:
https://github.com/brave/brave-browser
There are instructions there for building from source. We should have builds available sometime next month
We're still looking into this issue
+1 on this. Read through a whole load of previous threads for a fix before I found this one - none worked. Glad to hear it's being worked on as it's the only major issue I've found since switching to Brave.
Keep up the great work!
It seems that we silently fail to create an indexeddb (cvp-wasm-db).
It is part of the process of downloading and instantiating the wasm(http://cvp.twitch.tv/2.5.16/wasmworker.min.wasm).
The creation of the indexeddb is at line 227 of wasmworker.min.js wasmworker.min.js.zip:
var f = indexedDB.open(a, 1);
f.onerror = d;
f.onsuccess = function () {
c(new g(f.result, b))
};
f.onupgradeneeded = function () {
f.result.createObjectStore(b)
}
The debugger hangs after indexedDB.open as I cannot make the next step. It looks like script execution hangs on that call.
onsuccess, onupgradeneeded are never fired in Brave, but are fired in Chrome.
onsuccess is required to fire in order to download and instantiate the wasm at line 255:
return v.resolve().then(function () {
return WebAssembly.instantiateStreaming(fetch(b),
a)
})
Generally indexeddb works, so maybe execution path is what matters.
p.createWorker = function (e, t, i) {
var n = `\n var Module = {\n WASM_BINARY_URL: '${t}',\n WASM_CACHE_MODE: ${i}\n }\n importScripts('${e}');\n `;
return new Worker(URL.createObjectURL(new Blob([n])))
},
var Module = {
WASM_BINARY_URL: 'https://cvp.twitch.tv/2.5.16/wasmworker.min.wasm',
WASM_CACHE_MODE: true
}
importScripts('https://cvp.twitch.tv/2.5.16/wasmworker.min.js');
@btlechowski could be related to this one https://github.com/brave/browser-laptop/issues/12463?
@bsclifton @NejcZdovc My next step was to check if indexeddb fails in a webworker.
So indeed indexeddb fails in web worker and seems to be the root cause of this issue.
Got a fix for this (for real this time)! Hang tight folks
Verified on Windows 10 x64 using
7.1.5
67.0.3396.103
Verified on Ubuntu using
7.1.5
67.0.3396.103
Verified on macOS using
7.1.5
67.0.3396.103
ETA on production rollout?
@chuckreynolds possibly today - you can upgrade now if you wanted:
https://github.com/brave/browser-laptop/releases/tag/v0.23.31dev
If you're on Windows or macOS, you can also launch Brave with the BRAVE_ENABLE_PREVIEW_UPDATES=TRUE
environment variable set and check for updates 馃槃
Most helpful comment
Got a fix for this (for real this time)! Hang tight folks