Screen locked on remote computer

[BSlickMusic]

Anyone having this issue? I played a little bit last night with no issues, but now I can't play anything at all. When I try to open anything, I get the "Screen locked on remote computer" error, and my host computer has gone to the login screen. Even after logging in to the host computer, and trying to stream again, it goes back to the login screen giving me the same error. The host computer is Win 8.1, streaming to Win 7.

[[58th]tazerwhip]

Had a similar type issue with my setup.
On the Host 8.1 machine go to control panel.
System/Security (Category) > Power Options
Whatever plan is selected, go to change plan settings to the right of it
Now Change Advanced Power Settings.
Click the Change Settings That Are Currently Unavailable link. (Admin)
The first tree option should expand to 'Require Password on Wakeup' change to 'No'
Apply, OK

This is because your screensaver kicks in, or power settings turn the monitor off, and it locks the machine until activity again.

That solved it for me. Though I was having the stream pause mid-game.

[BSlickMusic]

We're getting somewhere, my settings were set to yes, although the issue is still there. It's really weird. It's not like my computer has sat a long time and eventually went to lock screen, literally, I'll log back in, go back to my laptop and hit stream on a game, and gives me the error. Literally seconds after I've logged back in, and then the screen goes back to lock screen. Only happens as soon as I try and stream again.

[BSlickMusic]

Bump!

Am I really the only one that has had this issue?

[Waldbaer]

No, you're not. My problems are similiar. My remote PC does not have a screen at all and it gives me the same failure message. I do not know why it would be necessary to have a monitor to stream it to a laptop which of course has a screen.

So I would love to have a solution. Do I really need to connect a monitor with my remote PC to be able to stream? I do not think that this would be a useful way...

Please advise!

Thanks!

[Valina]

I've been getting the same problem since 2 days ago I believe.
Host: Windows 7 Pro. Phenom II x4, 8gb ram, AMD 6850.
Client: Linux (usually Xubuntu, tried Wattos, Puppy and stock Ubuntu) Athlon x2, 4gb ram, HD4250 integrated GPU.

It used to work great until then, I tried different client OS'es, different remote streaming settings, ethernet, wlan, putting steam in Big Picture. Tried updating drivers on the host, tried both propriatery and opensource drivers on the client. The only thing perculiar about my system is that I use a program called SoftXpand to enable 2 concurrent users on my host machine. This worked perfectly before though and other remote desktop like RDP/Splashtop/VNC work perfectly, so not sure if it's related.

Edit: In Win7 Power Options>Require a password on Wakeup, it was set to require, but changing it didn't help. My power options are all set to always on basically aswel, so the screen isn't actually locking.

Edit2: Delved in the logs.
Healthy log
-----------------------------------

[2014-02-10 04:39:08]
=====================================================================
Game: Dark Souls: Prepare to Die Edition (211420)
[2014-02-10 04:39:08] Recording on device: Speakers (High Definition Audio Device)
[2014-02-10 04:39:08] Audio client mix format:
[2014-02-10 04:39:08] format: 65534
[2014-02-10 04:39:08] channels: 2
[2014-02-10 04:39:08] samples/sec: 44100
[2014-02-10 04:39:08] bytes/sec: 352800
[2014-02-10 04:39:08] alignment: 8
[2014-02-10 04:39:08] bits/sample: 32
[2014-02-10 04:39:08] channel mask: 0x3
[2014-02-10 04:39:08] data format: {00000003-0000-0010-8000-00AA00389B71}
[2014-02-10 04:39:08] Initializing audio with 2 channels and 44100 samples/sec
[2014-02-10 04:39:09] Detected 3 logical processors, using 1 threads
[2014-02-10 04:39:09] Capture method set to Desktop BitBlt RGB
[2014-02-10 04:39:10] Capture method set to Game D3D9 RGB
[2014-02-10 04:39:22] "SessionStats"
{
"TimeSubmitted" "1392003562"
"ResolutionX" "800"
"ResolutionY" "450"
"DecoderName" "libavcodec software decoding with 1 thread"
"BandwidthLimit" "10000"
"FramerateLimit" "30"
"SlowSeconds" "0"
"SlowGamePercent" "0"
"SlowEncodePercent" "0"
"SlowNetworkPercent" "0"
"SlowDecodePercent" "0"
"AvgClientBitrate" "6.3131852149963379"
"StdDevClientBitrate" "5.613555908203125"
"AvgServerBitrate" "214.59645080566406"
"StdDevServerBitrate" "2513.7109375"
"AvgLinkBandwidth" "6403.3583984375"
"AvgPingMS" "0.54083931446075439"
"StdDevPingMS" "0.15222719311714172"
"AvgCaptureMS" "8.0145263671875"
"StdDevCaptureMS" "5.3309788703918457"
"AvgEncodeMS" "5.1592340469360352"
"StdDevEncodeMS" "3.3864703178405762"
"AvgNetworkMS" "0.097249351441860199"
"StdDevNetworkMS" "0.21948042511940002"
"AvgDecodeMS" "4.9199762344360352"
"StdDevDecodeMS" "3.1021232604980469"
"AvgDisplayMS" "4283462.5"
"StdDevDisplayMS" "10914743"
"AvgFrameMS" "63.584510803222656"
"StdDevFrameMS" "87.473182678222656"
"AvgFPS" "25.05517578125"
"StdDevFPS" "12.388830184936523"
}

Log from "Screen locked"
-------------------------------------------------------------

[2014-02-14 18:37:47]
=====================================================================
Game: Dark Souls: Prepare to Die Edition (211420)
[2014-02-14 18:37:47] Recording on device: Speakers (High Definition Audio Device)
[2014-02-14 18:37:47] Audio client mix format:
[2014-02-14 18:37:47] format: 65534
[2014-02-14 18:37:47] channels: 2
[2014-02-14 18:37:47] samples/sec: 44100
[2014-02-14 18:37:47] bytes/sec: 352800
[2014-02-14 18:37:47] alignment: 8
[2014-02-14 18:37:47] bits/sample: 32
[2014-02-14 18:37:47] channel mask: 0x3
[2014-02-14 18:37:47] data format: {00000003-0000-0010-8000-00AA00389B71}
[2014-02-14 18:37:47] Initializing audio with 2 channels and 44100 samples/sec
[2014-02-14 18:37:49] Detected 3 logical processors, using 1 threads
[2014-02-14 18:37:49] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Capture method set to Desktop BitBlt RGB
[2014-02-14 18:37:51] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Capture method set to Game D3D9 RGB
[2014-02-14 18:37:53] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Capture method set to Desktop BitBlt RGB
[2014-02-15 03:50:28] "SessionStats"
{
"TimeSubmitted" "1392432628"
"ResolutionX" "1366"
"ResolutionY" "768"
"CaptureName" "Desktop BitBlt RGB"
"DecoderName" "libavcodec software decoding with 1 thread"
"BandwidthLimit" "10000"
"FramerateLimit" "30"
"SlowSeconds" "3.0151519775390625"
"SlowGamePercent" "0"
"SlowCapturePercent" "0"
"SlowEncodePercent" "100"
"SlowNetworkPercent" "0"
"SlowDecodePercent" "0"
"AvgClientBitrate" "3.1114585399627686"
"StdDevClientBitrate" "3.4475300312042236"
"AvgServerBitrate" "2315.05419921875"
"StdDevServerBitrate" "-1.#IND"
"AvgLinkBandwidth" "1.#INF"
"AvgPingMS" "0.41806945204734802"
"StdDevPingMS" "0.3061845600605011"
"AvgCaptureMS" "10.751565933227539"
"StdDevCaptureMS" "1.1305131912231445"
"AvgEncodeMS" "13.853971481323242"
"StdDevEncodeMS" "4.4485206604003906"
"AvgNetworkMS" "0.036592461168766022"
"StdDevNetworkMS" "0.21986448764801025"
"AvgDecodeMS" "12.356009483337402"
"StdDevDecodeMS" "4.9050278663635254"
"AvgDisplayMS" "121.031005859375"
"StdDevDisplayMS" "13587.9189453125"
"AvgFrameMS" "47.22802734375"
"StdDevFrameMS" "9.5224466323852539"
"AvgFPS" "29.697364807128906"
"StdDevFPS" "5.5300207138061523"
}
"StdDevServerBitrate" and "AvgLinkBandwidth" seem to be giving faulty values, some do give non INF values but they seem to be wrong either way. Hope someone knows how to interpret this.

[Valina]

POSSIBLE FIX: Apparently in my case, this was a problem with SoftXpand and the new Steam Beta having RDP detection, simly adding the Steam exe's (just added all of em) to the "Tasks with RDP hiding" in SoftXpand solved it for my case. I realise this is pretty specific though but if you have anything running related to RDP (maybe teamviewer or something?) closing that and relogging into a "proper desktop session" might do the trick for you. More info also at: http://steamcommunity.com/groups/homestream/discussions/1/540732888853346946/

[Sprinx]

If you're using a headless PC as the game server, then every time you log into this PC via remote desktop, the screen is locked. It doesn't matter if you have a physical screen hooked to it or not.

I have my PC set to automatically log into Windows with my password (run --> "control userpasswords2". Uncheck "Users must enter a username and password to use this computer." Then enter your user and password that should be logged in each time.

This would set your PC to always be available after reboots, and you wouldn't have to log in with the keyboard.

But my main point is that after you log in with RDP, the screen is locked. If you "Disconnect" the session, then the screen remains locked until someone logs in physically at the remote computer.

To fix this, go to your desktop on the gaming PC (host), right click, and choose "create shortcut"

Paste this command into the "target" field:

C:\Windows\System32\tscon.exe %sessionname% /dest:console

Set the shortcut to always use administrative privileges. Always use this shortcut to end an RDP session - never use "Disconnect"!

This pushes your session back to the console screen (meaning the screen is no longer locked).

I use this on my HTPC all the time.

(Edited on 2014-1-4 to use %sessionname% variable)

[dan0001]

I have the same issue as I use rdp quite a bit to connect to my steam games server. I haven't tried the destination console fix yet, but I have read in the other quoted thread above that this then gives an input issue on the pc in question (keyboard and mouse no longer work).

Fundamentally though, I don't think it matters if this fix works or not as I do not understand the reason the streaming client cannot distinguish between a connected and disconnected rdp session. Before this update, if I disconnected then streaming worked again yet now if I disconnect I am "screen locked". I completely understand that there would be an issue streaming if an rdp session was connected, but I don't see why it should be stopped if an rdp session if disconnected (especially with the fact it worked before the update).

I have found rdp very useful during testing streaming (aside from the fact I use it constantly for other reasons) when I encounter a game that needs input or further installation when starting (I have a library full of unplayed games as a result of the demon sales!).

So my thoughts are that I should be able to connect and disconnect at will from the remote steam PC via rdp and not have a disconnected session affect the streaming client.

[Stebe]

I also noticed this. It really is odd to me that a feature that seems to be specifically geared towards steaming content from a remote, headless unit would be stymied by console being locked on the remote unit (since leaving remote units with logged in consoles is a pretty bad idea, even if it is in your home).

[Waldbaer]

Hey Sprinx,

you are magic -> this did it for me. Thanks a lot!

[Sprinx]

Originally posted by dan0001:

I have the same issue as I use rdp quite a bit to connect to my steam games server. I haven't tried the destination console fix yet, but I have read in the other quoted thread above that this then gives an input issue on the pc in question (keyboard and mouse no longer work).

Hmm...I've never had any problems with this shortcut on my HTPC (which has a bluetooth keyboard and touchpad) or my gaming desktop.Give it a try - i might just work.

Originally posted by dan0001:

Fundamentally though, I don't think it matters if this fix works or not as I do not understand the reason the streaming client cannot distinguish between a connected and disconnected rdp session. Before this update, if I disconnected then streaming worked again yet now if I disconnect I am "screen locked". I completely understand that there would be an issue streaming if an rdp session was connected, but I don't see why it should be stopped if an rdp session if disconnected (especially with the fact it worked before the update).

I have found rdp very useful during testing streaming (aside from the fact I use it constantly for other reasons) when I encounter a game that needs input or further installation when starting (I have a library full of unplayed games as a result of the demon sales!).

So my thoughts are that I should be able to connect and disconnect at will from the remote steam PC via rdp and not have a disconnected session affect the streaming client.

I see your point here, especially since it worked before the update. Only thing to do is report it in the bug list and hope they find a way to not require an unlocked PC for the game streaming server.

Originally posted by Waldbaer:

Hey Sprinx,

you are magic -> this did it for me. Thanks a lot!

Glad I could help! You can also choose a custom icon for it if you want (I chose a red X included with Windows).

Just keep in mind that my method leaves your PC completely insecure to anyone else who can physically access it. Not a big deal for me, as mine is in my house which I share with only my wife.

But if you live with roommates or something where this could be an issue, or if the gaming PC is a laptop, just know this and decide if it matters to you.

[dan0001]

Hi Sprinx,

Thanks for that! I added it to the bug list. I did a quick search to see if it was already there, but it looked like there were only hits for the main discussion rather than the bug list. I am sure they have a mechanism for dealing with dupe anyway :)

[pogden]

hopefully this will be fixed soon. I can't leave my headless machine unlocked, It has to use a password or this is a deal breaker, which will be a real shame.

I'm also hoping this doesn't become a common theme once its out of beta, requiring suchj stringent locks on outside services and processes.,

[thousandfaces]

Easy workaround is to use Chrome Remote Desktop.

Log in via CRD and then disconnect. This should leave your machine unlocked.

[Breakfast]

Use Chrome Remote Desktop or UltraVNC if you see Google as an untrustworthy Big Brother. The screen lock issue is frustrating. Maybe they could build something into the Steam client or streaming part of the UI to let you initiate the connection/screen view without actually starting a game. UVNC can be fussy and I don't like relying on it and CRDP requires me to remember even more passwords.