cancel
Showing results for 
Search instead for 
Did you mean: 

Tsu's Posts

If Stadia cannot connect to a WebRTC server that’s for chat, you also get thrown out of any game. Try blocking your microphone for stadia.com! https://community.stadia.com/t5/Getting-Started-With-St... See more...
If Stadia cannot connect to a WebRTC server that’s for chat, you also get thrown out of any game. Try blocking your microphone for stadia.com! https://community.stadia.com/t5/Getting-Started-With-Stadia/cannot-start-any-games/m-p/41892#M1789 (I resorted to using Discord for voice-chat with friends.)
Is this perhaps another instance of Stadia not detecting the screen resolution correctly? https://community.stadia.com/t5/Stadia-on-Chrome/Stadia-4k-issue-fine-on-CCU-PC-can-t-detect-4k-monitor-VP9/m... See more...
Is this perhaps another instance of Stadia not detecting the screen resolution correctly? https://community.stadia.com/t5/Stadia-on-Chrome/Stadia-4k-issue-fine-on-CCU-PC-can-t-detect-4k-monitor-VP9/m-p/73639#M4570 In other words, do you have a screen with more than 96dpi, or do you have a zoom level set with Chrome?
I’d love to get one of those Dongles since I now have a 4K screen and Stadia suffers from that “resolution not recognized” bug on HiDPi screens. Gave my original dongle to a friend (who’s also on St... See more...
I’d love to get one of those Dongles since I now have a 4K screen and Stadia suffers from that “resolution not recognized” bug on HiDPi screens. Gave my original dongle to a friend (who’s also on Stadia) because there was no use for it for me while on 1080p.
The ad is still up: … But when I have it in my cart, it’s 80€ all of the sudden: This is a forbidden practice here, called „Lockangebot“.
After some digging I have learned, Stadia relies on the return value of the likes of `window.screen.width`, ignoring that the value is untrue as it gets decreased on high-density screens. For exampl... See more...
After some digging I have learned, Stadia relies on the return value of the likes of `window.screen.width`, ignoring that the value is untrue as it gets decreased on high-density screens. For example, my screen is 3840px wide, `screen.width` reports it as 2254px. You could be tempted to take into account the devicePixelRatio—which once more will get you, Stadia dev, an erroneous result (press F12): ```js // DO NOT DO this, unless you like tinkering with floating point numbers. width = window.screen.width * (window.devicePixelRatio || 1); width // is 3454, which still isn’t the correct 3840 ``` … better yet, query something that doesn’t get changed on zoom levels or system text scaling settings. (Please forward it to the devs,  @ChrisFromGoogle  , as I believe this could help and save time.)
Seconding that. My settings under “performance” show I have selected “4K / pro” as max, but pressing ctrl+shift in any games will show “4K is not supported on your device” even though its screen res... See more...
Seconding that. My settings under “performance” show I have selected “4K / pro” as max, but pressing ctrl+shift in any games will show “4K is not supported on your device” even though its screen resolution is 3840×2560 (at 60Hz).
The culprit in file “Preferences” is "media_stream_mic" (→ .profile.content_settings.exceptions.media_stream_mic). Removing it—or just blocking the microphone for Stadia in chrome://settings—solves i... See more...
The culprit in file “Preferences” is "media_stream_mic" (→ .profile.content_settings.exceptions.media_stream_mic). Removing it—or just blocking the microphone for Stadia in chrome://settings—solves it. I can start games after the first session. It apears to me that whatever Stadia contacts for voice-chat is faulty, throws an error, and any switch to the actual game streaming is being aborted by the (silent) error. Without a microphone made available everything works fine because the the erroneous path in Stadia's JS is not being taken or triggered. On any first and fresh Chrome/Chromium run I'm being asked whether to allow Stadia to access the microphone. As a human I'm too slow to react and grant the permission, hence the microphone is not available when the transition to game streaming happens and the error is not triggered on that very first start as well. (Please forward it to the devs, @ChrisFromGoogle , as I believe this could help and save time.) (I really wish I'd not have to do QA work for y'all for free.)
Well, the issue occured again: The first game session will start, the second will never and I'm thrown out as described initially. I've taken it upon myself to write a script that bisects by deletin... See more...
Well, the issue occured again: The first game session will start, the second will never and I'm thrown out as described initially. I've taken it upon myself to write a script that bisects by deleting half the files at random in the Chrome v88 profile folder. If I set “it worked” then half of these get deleted at random, else the previously list is used for that. Again, bisect. That's the results, the higher the number the more likely deleting that folder mitigates the issue:   5 ./Reporting and NEL-journal 6 ./Accounts 6 ./Feature Engagement Tracker 6 ./Network Persistent State 7 ./GPUCache 7 ./Storage 14 ./Preferences   As “Preferences” is regenerated whenever deleted, I do suspect Stadia stores something in there that contributes to the error (second start won't do).
Happy to report it works with Chrome v88.
In my case, the issue presents with Chrome v86 (stable) and v87 (beta), but does not with v88 (unstable)—i. e., specifically v88.0.4315.5 works.
It's a constant now, I cannot start any games since a few days. I've tried the following: Chrome  86.0.4240.183 (Official Build) (64-bit) 87.0.4280.27 (Developer Build) Ubuntu 20.04 (64-bit) ... See more...
It's a constant now, I cannot start any games since a few days. I've tried the following: Chrome  86.0.4240.183 (Official Build) (64-bit) 87.0.4280.27 (Developer Build) Ubuntu 20.04 (64-bit) … no difference. turned DNSSEC off (globally and for the link) tried exclusively Google's DNS servers (8.8.8.8 …) (flushed caches, rebooted) tried exclusively my ISP's DNS servers The only difference I've noticed is that I did have to sign in again. I've turned off HW acceleration (independently whether available with the build) through chrome://flags checked the developer console (ctrl+shift+i), no errors whatsoever logged (just many small requests) (My speed is 140/60 up/down according to various speed tests, like fast.com, but only 8 mbit down according to “projectstream.google.com”. Google's nameservers, IPv4+IPv6 running.) Update: projectstream.google.com now has my speed as 70 mbit down. Issue still exists. No problem starting any games on my mobile, through the Stadia App's experimental feature. But I don't intend to be limited to playing on my mobile. When I select a different game to start, I get told the old session that is running will be closed. Before getting thrown back to game selection as above. No wifi, no router; Desktop PC hooked up to the internet through a “dumb modem.” I'm effectively excluded from Stadia and the games I've claimed and purchased.
I'm experiencing this as well today. Maybe my input could move this forward a bit faster? Yes, it's the most recent version of Chrome (I've tried Chromium as well, i. e. without any extensions) as d... See more...
I'm experiencing this as well today. Maybe my input could move this forward a bit faster? Yes, it's the most recent version of Chrome (I've tried Chromium as well, i. e. without any extensions) as distributed through dl.google.com . Linux, no antivirus. I believe I've the knowledge to rule out any non-targeted infection. Both, pointer lock options and hardware accelerated video decode are set as they should. (Both won't affect Google/Stadia erroneously mismatching me with any running game sessions on their side, I highly suspect.) I'd love some specific, non-generic, instructions on how to troubleshoot this. This is not about graphics artifacts, after all, but connecting with the game session that's been started server-side (supposedly).