• Support

  • I've tried everything to fix this issue and it still persists... Please help!

Hello Team,

I have this god awful bug with my client. Whenever I hover over a video to preview it, it will load and preview fine.

However when I then move my pointer away from the video being previewed it instantly freezes and I have to manually close the app and reopen it.

I have a HP Reverb 2. I have updated any and all drivers I could find but nothing really helps. Is there an error log I can find and post here? Because it doesn't present any error messages when it crashes.

I need some way to debug this cause im just taking shots in the dark on this one.

Any assitance would be much apprecaited !

    Found my error log. in all the crashes I have the same errors starting with "Capturing Scene Focus" and ending with "Sun Oct 03 2021 05:58:02.850 - Screenshot: Hook Screenshot called with types:
    Sun Oct 03 2021 05:58:02.850 - 5"

    hope it helps

    Sun Oct 03 2021 05:57:54.679 - SLR.dll 1.19.7 startup with PID=19224, config=F:\Programs\Steam\config, runtime=F:\Programs\Steam\steamapps\common\SteamVR
    Sun Oct 03 2021 05:57:54.679 - vrclient type=VRApplication_Scene
    Sun Oct 03 2021 05:57:54.683 - [Settings] Load Default Json Settings from F:\Programs\Steam\steamapps\common\SteamVR\drivers\htc\resources\settings\default.vrsettings
    Sun Oct 03 2021 05:57:54.684 - [Settings] Load Default Json Settings from F:\Programs\Steam\steamapps\common\SteamVR\drivers\lighthouse\resources\settings\default.vrsettings
    Sun Oct 03 2021 05:57:54.684 - [Settings] Load Default Json Settings from F:\Programs\Steam\steamapps\common\SteamVR\drivers\null\resources\settings\default.vrsettings
    Sun Oct 03 2021 05:57:54.684 - [Settings] Load Default Json Settings from N:\Local Disk N_91420212214\Video Games\SteamLibrary\steamapps\common\MixedRealityVRDriver\resources\settings\default.vrsettings
    Sun Oct 03 2021 05:57:54.684 - [Settings] Load Default Json Settings from F:\Programs\Steam\steamapps\common\SteamVR\resources\settings\default.vrsettings
    Sun Oct 03 2021 05:57:54.685 - [Settings] Load Json Settings from F:\Programs\Steam\config\steamvr.vrsettings
    Sun Oct 03 2021 05:57:54.688 - Client (SteamVR_Namespace) app container state: 1
    Sun Oct 03 2021 05:57:54.689 - CSharedResourceNamespaceClient::Init(): received namespace data 15672
    Sun Oct 03 2021 05:57:54.689 - Client (VR_ServerPipe_15672) app container state: 1
    Sun Oct 03 2021 05:57:57.238 - Received success response from vrserver connect
    Sun Oct 03 2021 05:57:57.240 - Not looking for a good app key because Steam didn't start this app
    Sun Oct 03 2021 05:57:57.240 - App key after connect message:system.generated.slr.dll
    Sun Oct 03 2021 05:57:57.244 - Client (VR_CompositorPipe_15672) app container state: 1
    Sun Oct 03 2021 05:57:57.253 - Received success response from vrcompositor connect
    Sun Oct 03 2021 05:57:57.253 - Initializing the limited version of CVRCompositorClient
    Sun Oct 03 2021 05:57:57.253 - Attempting to load initial input config
    Sun Oct 03 2021 05:57:57.255 - No controllers detected. Not waiting for config.
    Sun Oct 03 2021 05:57:57.431 - Capturing Scene Focus
    Sun Oct 03 2021 05:57:57.746 - Found Windows 10 or newer, so enable advanced image processing of scene textures.
    Sun Oct 03 2021 05:57:57.755 - Setting max texture dimensions to 5056x4944 before requiring downsampling
    Sun Oct 03 2021 05:58:02.850 - Screenshot: Hook Screenshot called with types:
    Sun Oct 03 2021 05:58:02.850 - 5
    Sun Oct 03 2021 05:58:02.850 -
    Sun Oct 03 2021 05:58:02.927 - Unknown action set /actions/htc_viu
    Sun Oct 03 2021 05:58:22.192 - VR_Shutdown called

    6 days later

    Rakly3
    Hello Rakly,
    I gave that threads suggestion a shot but it had no change for me. i deleted the registry and the appdata files then rebooted and installed deo vr.

    Any other suggestions?

        songbird

        Sun Oct 03 2021 05:57:57.255 - No controllers detected. Not waiting for config.

        Reinstall StamVR and Steamworks. Possibly even WMR
        They are both under Tools.

        F:\Programs\Steam\steamapps\common\SteamVR\drivers\lighthouse\resources\settings\default.vrsettings

        Which controllers are you using?

          2 months later

          I got a Rift S and had this problem for a week, I tried the mentioned fixes but wasn't successful with them.
          I had never problems with the app before.

          I already completly reinstalled the SLR app and DeoVR like mentioned in the guide and SteamVR + Steamworks through Steam and couldn't get rid of these problems.

          Is there anything else I can try? where can i get these logs from?
          Thanks in advance

          Sorry for bumping this post but i thought it would be better than creating a new one

            LordCrash
            I'm on a Rift S as stated in my previous comment. I never had WMR installed.

                5 months later

                Hey ilp4e, LordCrash and @Rakly3

                After 6 and a half months I finally identified what caused the issue for me. I've always despised the people online who found the answer to their issue and never shared it. Well Not This Degenerate of a man, I have principles! Heres all the details hopefully it helps.

                To recap the issue was if I ever was to launch the app and hover the cursor over a video or live stream, it would take a second then begin displaying the preview of the video / stream. As soon as I moved the cursor away from the rectangle box showing the video, the whole app froze and crashed. BUUTTT if I clicked before the preview could load , then the video it wouldn't crash, well intially anyway. it would run for a short while maybe a minute then crash. Similar story with the live VR streams when previewing but it wouldn't crash at all if I entered the cam room before loading the preview which was odd but it was abit more unstable.

                So what was it?

                Mother Fucking Malware Bytes, the virus protection software. I have the premium version and it comes with malware web protection. As soon as I turn that setting off ... Vuala the issue has gone. Then if I turn it back on same issue comes back, so pretty certain this is whats doing it for me.

                For anyone that has this same problem looking for a solution. You can turn off the web protection or even better just add "www.sexlikereal.com" to the allow list. It will stop flagging the domain / Ip adress as malicous. That way you won't have to switch off web protection everytime you use SLR. If you don't have a Anti-Virus check your firewall incase its blocking anything and I think windows has its own anti-virus just don't think it covers web traffic but try switching it off and test, if all else fails.

                Maybe the devs can implement a patch to fix this specific scenario? Here's my theory on whats going on based on my experience with the issue.

                It's the IP address of the server that "www.sexlikereal.com" is being hosted on, It's being flagged as malicous as soon as I try to stream video content. The packets coming from that IP are being dropped by the antivrus cutting the client off from the server connection probably during the video streaming. The log shows "Capture Scene Focus" which sounds like some code ran on the app to iniate a streaming state and as soon as I moved my cursor it ran more code by accessing something in the HTC files in order to exit that video streaming state.

                Then perhaps the crash that follows is related to loosing the flow of data between the server and the client / SLR App which causes a critical error and the app to crash. The message shown on the log before the "VR_Shutdown" command says "Unknown action set /actions/htc_viu". That means it looked for a resource but couldn't find it right? Maybe that means before the "action set" is retrieved from that folder it needed to be requested via HTTP POST request but due to the antivirus blocking the IP it gets a 403 and fails to retrieve it. The rest of the code can't continue to run, so the code fails.

                Another related detail is that entering the VR cam rooms would work even if the antivurs was on. That makes sense since each streamer would be broadcasting their stream off their local IP. Their public and private IPs are all different from the main SLR IP. This means they don't get flagged, because they are not directly tied to SLR. So making a connection to them doesn't cause a crash.

                To add more credence to the theory, if I ever tried to preview the live VR stream it would crash just like the VODs. I know those preview clips aren't actually live, they're just highlights stored on the SLR server. I'm thinking that's the case because, puttng it on the SLR server would have greatly reduced the number of request users make on the streamers streams which makes it a more stable connection and reduce cost. This would explain why loading the previews of the streamers crashed, its coming from SLR. However, connecting to the stream without loading the preview didn't crash because you would be only making a connection to their local IPs and not the problematic SLR IP.

                Not sure if its fixable, but maybe add an error message that pops up telling the user they've lost connection and to check their antivirus settings. I think that would be enough for most people to work it out themselves, at the least.

                      songbird After 6 and a half months I finally identified what caused the issue for me.

                      Happy for you, mate! And thanks for sharing.

                        songbird

                        Well that is one reason why you should never use security software outside your OS.
                        The OS should be the only one responsible for your security, 3rd party software in best case does nothing worse, sometimes lead to completely unexpected behavior like for you and in worst case tear severe security holes in your system. And they are usually extremely severe, as security software always runs on elevated rights to do its job, so any security hole in it automatically gives the attacker elevated rights as well.

                            Hey ibins

                            Thanks for the insight friend,

                            I think that's a perfectly valid point to make, however the OS provided security is limited in its protection scope. I understand a 3rd party software given elevated rights is a potential security weakpoint but it's main purpose is to detect well hidden malware in startup, registry, memory and files rather than viruses, I leave the virus protection to windows security because it is simply better, I did refer to Malwarebytes as anti-virus but that isn't really accurate.

                            Malwarebytes' permissions are read only while it detects and to remove any files requires my manual authorisation. The live web traffic feature does have permission to block IP addresses but that's done via a machine learning/ crowdsourced white/black list and can be disabled, I assume enabling this feature is the more risky option. Ultimately It's detected alot of unsavoury registry entries, malicous sites and malicous files which wern't picked up by windows alone so it serves its purpose.

                            Even if it opens me up to the risk you mentioned the likely hood of that happening has been proven to be much less than the risk of picking up the more common malware threats out there. So in my mind the benefit outweighs the risk and in my use case being a low priorty target for hackers as opossed to an enterprise with higher value data it makes sense.

                            I am curious though, what is your security setup like? I am an IT professional but not a security specliast so I could be suffering from the dunning kruger effect.

                                songbird

                                I think that's a perfectly valid point to make, however the OS provided security is limited in its protection scope.

                                Just the opposite, the OS can do everything, any software running on this OS can only see and do what the OS allows. With most PC operating systems it is possible to load 3rd party software at kernel level, so it is technically possible to use this to scan for potential malicious behavior. But this is the same way that actual malicious software tries to hide, and the more that runs at kernel level, the higher the risk some exploit can be found and be used as an attack vector.

                                but it's main purpose is to detect well hidden malware in startup, registry, memory and files rather than viruses,

                                Which is exactly what 3rd party software can not provide. It is always the OS that starts the system, and it is the OS that loads your security software, the security software can only detect things that happen after it has been loaded, it can not detect startup manipulations.
                                For this purpose Secure boot has been invented, which is a function of the OS in conjunction with supported hardware.
                                This can detect manipulations at the lowest level, and prevent the OS from loading if anything has manipulated the startup procedure.

                                I leave the virus protection to windows security because it is simply better, I did refer to Malwarebytes as anti-virus but that isn't really accurate.

                                There is no reliable virus protection. There are so many viruses developed every day, that even with constant signature updates you can detect only about half of the viruses that exist. And heuristics have been proven unreliable, either detecting a large amount of false positives, or letting a high amount of unknown viruses slip.