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.