Possible duplicate of #5831.
Ha, yes, that does sound similar! ... Except that running windowed does not help; that every couple of tries it actually does work as expected; that it has already worked reliably on this very system (of course, both the host and client have had system updates, the host, being Zen 2, a BIOS one as well).
It feels like Steam has trouble recognising and/or switching from the desktop (2160p, Desktop_MovieStream / Desktop OpenGL NV12) to the game window (1080p, GameOverlay_MovieStream_*, Game Vulkan RGB) properly. It'd be interesting to know when & how a new record window is selected, especially when Proton is involved? Is it at all timing-sensitive (possible race-condition)? Is there any way to manually force a switch?
I'll happily (well, unhappily) sink another day or two into this, but poking around blindly has only yielded that the Steam version (stable/beta) doesn't matter; nor do any of the Remote Play settings; or Prey video settings; or Big Picture; nor setting the host's display resolution to 1080p and running Prey in fullscreen; and a Windows 7 client mis-behaves in exactly the same way.
Next idea: Proton versions.
So, yay, but I'd much rather the current Proton worked, in the long run. How to proceed? Close this one, re-open over at the Proton github? Anyway, I'd be happy to test/help/whatever.
FWIW, Proton 4.11-6 under the Steam beta dated September 23rd is still affected in the same way.
Not sure if it is strictly the same issue as it seems to only happen when I stream over the internet from a particular machine but I get the exact same issue described by the OP with Proton 4.11-* (tested up to the current 4.11-7) but previous versions of Proton work fine. This is with various games including: Think of the Children, Lego Star Wars, Death Squared and more. No issue with native games and older versions of Proton (4.2 and below). When I get the chance I'll see if I can reproduce with that machine over a local network.
Proton 4.11-7, Steam 2019-10-29, still affected (just for the record).
Proton 4.11-7, Steam 2019-11-06, 03:10:37, still affected,
but GloriousEggroll's 4.19-GE-1 works.
Since there's a workaround available (use 4.2 branch) and a high probability that it'll fix itself in one of the next major Proton releases, I'm happy. Will continue testing this periodically and report back once the current official Proton release works.
FWIW, I played Captain Spirit (845070) yesterday, and it streamed perfectly fine using Proton 4.11-11. Will re-test Prey shortly.
Prey works, as does Ori, as of Proton 4.11-11. Note that I didn't test all interim versions, the fix may well have got in earlier. Happy new year to you all! Closing.
proton 4.11-11x2 2020-01proton 4.11-7x2 2019-11proton 4.11x1 2019-10proton 4.11-6x1 2019-09
Your system information
Please describe your issue in as much detail as possible:
I'm trying to stream Prey (2017) from a Linux Mint 19.3 host [HWE enabled, AMD Radeon VII with mesa-aco from Valve's PPA, native resolution 3840x2160], a game which works perfectly locally, to a Ubuntu 18.04 client [native res. 1920x1080] When I start to stream it, I first get the host's desktop on the client, input and everything, that's normal. After a second or two I'd expect the host's desktop to be replaced by the game screen. What happens instead is that the streaming display on the client effectively freezes, while on the host the game launches normally. The client plays the game's sound, it's input is streamed to the host and affects the game just fine, even the mouse pointer moves both ends, it's just graphics that's effectively frozen. The performance overlay is frozen as well, showing insane (> 60 seconds) display latency. The streaming log doesn't tell me much, except that it never switches from desktop to game stream and effectively all frames get dropped for being late.
Now, I've tried rolling back to the stable channel, every setting under Remote Play settings, fullscreen/borderless/windowed in Prey, switching the host's desktop resolution to the game resolution beforehand, no cigar. That is, sometimes it just works, even two tries in a row, then nothing for the next ten. The fun part is, this used to work perfectly until August 16th, then I went on vacation for a couple of weeks, now it's borked.
I realise full well that there's too many variables for this to be a proper bug report, I'd be happy to flesh it out if someone were to tell me where to start.