VRChat (438100)

[Goofybud16]

System Information Original
System Information - Updated Jan 27, 2019

Problem:
Was able to load into the hub successfully after going through tutorial, but most other player models did not render correctly, if at all.
Upon restarting the game, it crashes upon loading into the hub.
Mouse keeps pulling towards the bottom right.
Game locked up on exit with a black screen.

All other behavior appeared to be correct.

[bytefaux]

I've found a couple workarounds for various issues listed here.

Crash on loading hub world: Setting launch option vrchat://launch?id= with another world id will load that world rather than the hub world. Been using wrld_8ef393c0-a985-4d7e-90f0-33ab10d41ee3:2822 here for the avatar testing world.

Mouse escape in windowed mode: Just set the -screen-fullscreen 1 -screen-width w -screen-height h launch options with the resolution of your screen as w and h.

Mouse sensitivity maxing out when opening/closing game menu: It's pretty annoying but it's fixed temporarily by switching focus from then back to the game by alt-tabbing or using a volume key so a popup showing the current volume quickly grabs and releases focus.

Game locks on exit: Just keep a command line open with killall VRChat.exe to bop the process after exiting :/

System: Ubuntu 18.04.1 LTS | Intel Pentium G3258 | GeForce GTX 750 Ti | Proton 3.7-7 Beta | VRChat 2018.3.1

[kassindornelles]

I have a problem with VRChat even with Stream Output support, the characters and everything on tutorial works fine but you can't load any map after that, the game just freezes.

Hardware/Software info:
Proton 3.16-1
GTX: 750 2 GB Driver 396.54.09
CPU: Intel Core 2 Quad Q9550
RAM: 7 GB

Here is the proton log file:
steam-438100.log.zip

[owlboy]

How have things changed with VRChat 2018.4.3? They just performed an engine upgrade along with upgrading various libraries they use.

[bytefaux]

@owlboy Not for the better unfortunately. VRChat 2018.4.3 segfaults now before even showing for me.

steam-438100.log

Edit 1: because this maybe related to my old cpu's lack of AVX support. Will update once try it on a supported cpu.

Edit 2: I upgraded to an i7 cpu with AVX support but had the same crashing issue until switching from proton 3.16-6 Beta to 3.16-4. Everything's back to working as well as it did before.

System: Ubuntu 18.04.1 LTS | Intel i7 4790 | GeForce GTX 750 Ti | Nvidia 396.54.09 | Proton 3.16-4 | VRChat 2018.4.4

[prototype99]

3.16-6 beta works fine for me at home, the menu and at a 40mb room, but a 220 or so mb would not work, using the tv hangs it, certain characters cause hangs. some of the avatars at 'loli's world' seemed to break it as well (one of the top results for avatar worlds) oh! also -force-d3d11 allegedly helps.
System: Gentoo 17.1 | AMD Ryzen 7 1800X | GeForce GTX 1070 | Nvidia 415.25 | Proton 3.16-6 | VRChat 2018.4.4

[Goofybud16]

I just tested it with 3.16-6 beta and can confirm that it works to some extent now-- Turning on the TV hangs it though. Going through several avatar worlds, the game seems to work just fine. I did notice a lot of hangs-- the hangs would cause some nasty mouse wackyness. Except for the TV, however, none of the hangs lasted more than a few seconds and the game resumed working after that. The exit button does appear to hang the game, but I don't see that as a huge issue (it is the Exit button....)

[prototype99]

ohhhh this reminds me of a few things i forgot to mention! yeah you have to externally end the process to exit. having any sort of controller plugged in seems to make the mouse 'stick'. however the hangs kept going for me. all hangs were related to certain avatars or to certain worlds (i reattempted the 220mb one A LOT and it always hanged seemingly permanently) i also have a terminal log, but i feel like there's not much useful info to obtain from it, the hangs don't SEEM to create any output
vrchat-log.txt

[owlboy]

VRChat has issues closing properly without hanging in some cases on its own on Windows. So that is not surprising.

[Goofybud16]

Since there isn't an issue for the VRChat VR version, and I believe that they are the same App ID (correct me if I'm wrong), I'm gonna add this here:

Once I got SteamVR working and happy, I was able to play several hours of VRChat in VR with my Vive with almost zero issues. There were 1 or 2 models that didn't render correctly, but that was an issue in desktop as well. Performance is about what I would expect from playing some VR games on Windows ~a year ago (last time I booted into Windows). I DID have Direct Mode working, and everything seemed to "just work" other than the Exit button in VRChat. All of the other bugs I hit seem to be actual bugs in the game itself, and weren't the fault of Proton.

Since my initial report was ~5 months ago, here is a new System Info gist to reflect the software changes that have occurred in that time: System Info. I'll add this to the OP as well.

[Worfhard]

In desktop mode the map "The Great Pug" crashes after ~10 seconds after you join.
Proton 3.16-6 Beta
sysinfo.txt
steam-438100.zip

[Goofybud16]

I've had that issue with the same map as well. I thought it was an avatar, but the map makes more sense because I kept crashing after turning Safety all the way up to max.

In VR, however, the map seems to be fine.

UPDATE: After posting this, I've tried to go to The Great Pug a few times, and it now crashes the game in VR. I'm not really sure what changed, if anything.

[Goofybud16]

I've put over 100 hours into the game at this point, and can say that it works pretty well. Since my last system specs post, I think I've bumped to Mesa 18.3.x, but that is about the only notable change.

So far the game has been working fine with Proton 3.16-7 Beta.

The only things I've found that consistently crashes me 100% of the time is the ingame embedded web player and some shader-heavy worlds. Any world that has an auto-activated web player will crash me within a minute, hitting the button to turn it on in any world where it must be activated will crash right away. Worlds with lots of really fancy shaders also seem to crash the game, but it could also just be something like shader (re)compilation taking so long that I think the game died.

The game hangs on exit 100% of the time. Sometimes when killing the game (clicking the X until KDE prompts to kill wine), it will completely or partially crash SteamVR. I've noticed this happens more when the game has locked up/crashed; however it handles it perfectly fine sometimes. Restarting SteamVR fixes the issue.

I've also noticed that opening and closing the SteamVR Dashboard overlay too many times too quickly can crash the game as well. I started noticing that with 1.2.10, but that could just be because I've spent many many more hours using 1.2.10 than using any other version.

Other than that, the only crashes I experience are usually things that crash other users as well (IE avatars with just insane shaders, lots of resource-intensive avatars in a small area). If anything I've found that I crash less than some other users who run on Windows, as the game seems to handle extremely resource-intensive avatar shaders "well" (The game drops to 1-2 FPS but keeps rendering which allows me to use the menu to leave the world). It isn't pleasant, but the game does survive.

I've also noticed an issue (although I don't know that I've seen it since Proton 3.16-7 Beta activated) where shaders or something seem to keep running. When avatars have really demanding shaders, if I leave the world to other (empty, decently optimized) worlds, I'll often keep having terrible performance. If I go to a world where I usually get 45 FPS, it will be consistently dropping below 30 despite me being the only person there. Restarting the game (and SteamVR, if SteamVR crashes) will fix this. I'll see if I can reproduce this with Proton 3.16-7 Beta; it may have been fixed.

Overall, I'd say that with decently powerful hardware (see my system specs), the game is absolutely playable and a pretty good experience. It isn't perfect (see above for the issues), but most of the issues are usually avoidable and manageable. I absolutely plan to keep playing the game for the foreseeable future, so long as it stays in the current state (or gets better).

[Goofybud16]

I may have found a fix for the video player crash (also fixes The Great Pug):

Browse to the VRChat folder in steamapps/common.

Browse to VRChat_Data, StreamingAssets, and rename youtube-dl.exe to something other than youtube-dl.exe (for example, youtube-dl.exe.no). This will disable the ingame streaming video player completely, but also fix the crashes. You won't be able to watch videos in maps anymore, but at least the game won't crash.

[prototype99]

hmmm.... youtube-dl has a linux version, i wonder if it is possible to redirect it so it uses the native one. considering it's a command line application i imagine the commands are the same on both OSes

[owlboy]

youtube-dl requires Microsoft Visual C++ 2010 Redistributable Package (x86) per their homepage.
https://www.microsoft.com/en-US/download/details.aspx?id=5555

https://rg3.github.io/youtube-dl/download.html

@Goofybud16 Can you confirm this is installed and available for youtube-dl?

[owlboy]

@Goofybud16 Here is a test world that has a Unity Video Player component in it, but it does not use any VRChat video scripts, so it should not call youtube-dl:

https://vrchat.com/home/world/wrld_f994e95a-8c0e-42b2-b894-f9cf6f1c6387

Upon loading, it should autoplay a video from a direct URL. This video should also loop.

If it could be used to test to see if this world also crashes VRChat under Proton, that might help confirm whether youtube-dl is specifically the issue or if it is the video player alone.

Thanks for continuing to test this.

[Goofybud16]

youtube-dl requires Microsoft Visual C++ 2010 Redistributable Package (x86) per their homepage.
https://www.microsoft.com/en-US/download/details.aspx?id=5555

@Goofybud16 Can you confirm this is installed and available for youtube-dl?

As far as what is installed: I just told Steam to use Proton 3.16-6 Beta (and now it uses 3.16-7 Beta after an auto update). I don't see anything for it in the Program Files or Program Files (x86) folders. Whatever Proton and VRChat installed as part of initial setup is all that is installed. What is the best way to install that/check for it?

@Goofybud16 Here is a test world that has a Unity Video Player component in it, but it does not use any VRChat video scripts, so it should not call youtube-dl:

https://vrchat.com/home/world/wrld_f994e95a-8c0e-42b2-b894-f9cf6f1c6387

Upon loading, it should autoplay a video from a direct URL. This video should also loop.

If it could be used to test to see if this world also crashes VRChat under Proton, that might help confirm whether youtube-dl is specifically the issue or if it is the video player alone.

Without Youtube-dl, that world doesn't crash, however it doesn't play a video either.

With Youtube-dl, the same exact thing happens. The video screen is just blank. In the console, I do get the line

Unloading 1 Unused Serialized files (Serialized files now loaded: 2)
UnloadTime: 1.459000 ms
WindowsVideoMedia error 0x80004001 while reading http://thegreatpug.com/video/other/dev_update-1.mp4

Context: Turning DXVA off
Error details: <Empty>
Track types:


(Filename:  Line: 2456)

Thanks for continuing to test this.

Not a problem. I'm just playing the game, most of the testing I've done comes as a result of trying to do something with friends and having it crash me.

As far as "what is the actual problem with the video subsystem", I suspect something on the VRChat side. The first time I go to The Great Pug after an update to the game/map (with youtube-dl), it works. However, all network connectivity outside of other player's movement and voice stops working. Portals don't load, avatars don't load, the menus are broken, and the game log gets filled with NullReferenceExceptions. Trying to Go Home will result in the game loading nothing forever. The second time I join the world, it will crash almost exactly at the 1 minute mark, hanging and maxing out 1 CPU core. Prior to hanging, the game breaks in pretty much the same way. I've had this in other worlds as well. In worlds without an auto-activated video player, the game seems to work fine until it gets turned on. Once it gets turned on, the game instantly hangs.

[owlboy]

@Goofybud16 Here is a build of a very basic Unity scene that has a video player configured as it is in my test world in VRC and is playing the same video. The version of Unity used is the same that VRC currently uses. No VRChat code or youtube-dl is involved in this build.
I tested on Windows 10 in VMware to confirm the build runs and plays the video as expected.

http://thegreatpug.com/share/test_video_player.zip

(This has Windows, and macOS builds in it. But no Linux build as I don't have the package installed in Unity right now)

[owlboy]

Re: How to install Microsoft Visual C++ 2010 Redistributable Package (x86) for a Proton install.

I am not sure. I actually don't have a Linux box running Proton, and I have never used Proton myself. I am just interested in VRChat, and it running on other platforms. And am trying to help the best I can.

[Goofybud16]

@Goofybud16 Here is a build of a very basic Unity scene that has a video player configured as it is in my test world in VRC and is playing the same video. The version of Unity used is the same that VRC currently uses. No VRChat code or youtube-dl is involved in this build.
I tested on Windows 10 in VMware to confirm the build runs and plays the video as expected.

http://thegreatpug.com/share/test_video_player.zip

(This has Windows, and macOS builds in it. But no Linux build as I don't have the package installed in Unity right now)

I temporarily replaced VRChat with Test Video Player (to replicate as close as possible the environment in use [same wine prefix]) and while it does load up, the video never plays. The video player just stays solid white. If I run with konsole -e %command% (to get a debug log) there isn't really any useful info in the output.

I suspect the problem is that Proton is missing some Windows Media components (or maybe has a bug in some implementation?), and that causes the video to fail to play, which VRChat does not handle well causing it to lock up as it tries to sync playback or something with a video player that isn't playing.

[JulianGro]

If we could figure out how to make and exe that is called by vrchat (youtube-dl.exe) to run a native linux application, we could have that just redirect the command to native youtube-dl.
I have tinkered a little bit with that, but unforunately just renaming an sh script to youtube-dl.exe and making it executeable doesn't work.
In my case i tried putting cmd /c start /unix /usr/bin/glxgears in to see if glxgears would run instead of youtube-dl.

On the other hand, looking at the proton logs when running owlboys testworld and the test_video_player shows that "mfplat.dll" is being loaded. "mfplat.dll" is part of the windows media feature pack. I tried replacing the builtin mfplat.dll with a windows native mfplat.dll from the windows media feature pack for windows 7. Unforutnately it fails to load.

[h1z1]

Could very well be VRChat embeds some config in their exe? I don't have a windows build environment atm. Testing in proton with a local file I get:

Z:\home\vrvm2\.local\share\Steam\steamapps\common\VRChat\VRChat_Data\Syoutube-dl --print-traffic asdf.mp4
Traceback (most recent call last):
  File "__main__.py", line 19, in <module>
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\__init__.py", line 472, in main
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\__init__.py", line 439, in _real_main
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\YoutubeDL.py", line 416, in __init__
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\YoutubeDL.py", line 2332, in _setup_opener
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\utils.py", line 700, in make_HTTPS_handler
  File "C:\Python\Python34\lib\ssl.py", line 439, in create_default_context
  File "C:\Python\Python34\lib\ssl.py", line 390, in load_default_certs
  File "C:\Python\Python34\lib\ssl.py", line 382, in _load_windows_store_certs
ValueError: Empty certificate data

Semi related, appears to be a bug upstream in Python itself:

if sys.platform == "win32":
    from _ssl import enum_certificates, enum_crls

[...]

def _load_windows_store_certs(self, storename, purpose):
        certs = bytearray()
        for cert, encoding, trust in enum_certificates(storename):
            # CA certs are never PKCS#7 encoded

[Casuallynoted]

I'm having an issue where it just kind of lingers at the login screen.
Currently using Proton 4.2-2, has anyone experienced this before?

[kisak-valve]

Hello @Casuallynoted, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

[Casuallynoted]

Oh wait! I left it running in the background and it seems to have done it. I've had this issue once on windows with the latest update so maybe it's a VRChat thing! Nevermind!

[Casuallynoted]

Tried it again now after a break, so... I was correct that it did load me into a world but everything else is taking centuries to load, including my avatar, social menu, and eventually the app does crash before loading anything aside from the home world. Logs included:

steam-438100.log

[Goofybud16]

After upgrading to 4-2.2, I haven't had any issues playing VRChat in VR. I haven't tested desktop mode yet.

[Casuallynoted]

After upgrading to 4-2.2, I haven't had any issues playing VRChat in VR. I haven't tested desktop mode yet.

That's really good to hear, are the video panel issues also resolved?

This is what I'm looking at atm, for some reason things don't load and inevitably hang. I can say I use VRC on the windows side of my PC and it's quite fast in terms of loading content.

[MehStrongBadMeh]

Once again, you are not correct.
This flip is a disparity from trying the same players in Windows which do not experience this issue.

[Lhun]

Strongbad, I promise you I am not talking out of my ass here. We do this every single day for an internationally recognized company.
RenderHeads/UnityPlugin-AVProVideo#284 <-
This is a commonly known thing. Avpro intentionally doesn't flip to save overhead in vr you're expected to flip the UV itself.
I promise all the players you're using are accounting for that. Use it raw on windows and you'll see it's the same.

[yshui]

@MehStrongBadMeh

What API does AVPro use to play m3u8? Does MF support playing directly from m3u8?

As for RTSP, gstreamer should already be able to handle that. Do RTSP streams not work either?

[MehStrongBadMeh]

@yshui I am no longer convinced the issue is related to m3u8. Although I also have no idea what is going on. I tried the example RTSP stream on this page: https://www.wowza.com/developer/rtsp-stream-test but it failed to play in Proton (works fine in Windows). We'll be releasing the update pretty soon, so you'll have an opportunity to try it out for yourself and see what is going on.

Sidenote: one of my co-workers mentioned that most of our users who set up RTSP streams actually use RTSPT, which was left out of the added scheme handlers for some reason.

[yshui]

which was left out of the added scheme handlers for some reason.

I think it's just neglect on my part. It would be pretty easy for Proton dev to add them, hopefully they will see this comment...

[Goofybud16]

How long would you generally be playing before getting the freeze?

@alasky17, it was usually within around 10 minutes that I'd see the freeze. Sometimes it was right away (joined a world and the game crashed); sometimes it was while sitting in a world talking with someone. Tried multiple worlds, none seemed to really help much (originally thought it was related to the video player, hence changing worlds).

Looking at chat logs, I believe the first day I observed the issue was July 6 towards the end of the day, and fixed it by rolling back to Proton Experimental non-bleeding edge. I had been running Bleeding Edge to get the Video player to work, seems like one of the last changes to Experimental Bleeding Edge prior to Experimental updating may have been related.

Testing in Desktop mode I wasn't able to reproduce the issue after about 20 minutes.

Testing results in VR mode (SteamVR 1.22.13, Index, Index Controllers, 3x Vive Tracker 2.0, 3x Basestation 2.0) :
Kernel 5.18.10 (Mainline + Debian 5.18 config + 1000Hz)

Proton Version	PROTON_NO_FSYNC	Crash
Experimental	Unset	Freeze (at startup)
Experimental 20220628	Unset	Perfectly fine for 20-30 minutes
Experimental Bleeding Edge (as of Jul 13)	Unset	Freeze (At startup)
Experimental	1	Works for hours, no problems
Experimental Bleeding Edge	1	Runs fine for 20-30 minutes

[happysmash27]

I also get a freezing issue. Usually it happens within the first few minutes or so, but once or twice it also happened after a much longer time – more than 30 minutes IIRC. Sometimes VRChat also just randomly and very suddenly crashes. The freezes are more common than the crashes though.

[Lhun]

Rtspt and rtsp are generally interchangeable for the purpose of vrcdn. For example, rtsp, (dropping the t), will work in vlc projector in obs using vrcdn relay. Rtspt will not (edit for clarity) work in OBS At the moment, but it's required for VRCDN in VRChat with AVPRO for low latency mode, but the rtsp address isn't even listed as a supporting stream format (in vrcdn, but it does work in OBS!). To be spicific, the Real Time Streaming Protocol itself is split into three: Rtspu is udp, rtspt is tcp, and rtsp is unspecified, or "autonegotiating" basically. Again if you need a proven working stream type hit me up. I can broadcast from anywhere in the world to any format vrcdn supports (you'll probably want rtspt!) from multiple sources simultaniously, including fmp4 or m3u8 or rtsp or etc, though I reccomend reaching out to them and working with them directly. Great group of people over there. For the purposes of Concerts in vrchat we always use rtspt and mpeg2 for quest as that's what they recommend for their service. For twitch it's m3u8 mp4 h.264 main 6000kbps 4.1 or so. For YouTube it's usually identical, except when it's occasionally vp8 or vp9, but iirc vrchat forces the quest compatible selection from static video and m3u8 for streams. Vimeo is identical. SoundCloud is audio only but probably doing something unusual like aac alone or vorbis. Topazchat in Japan uses rtsp straight up.

…

On Wed., Jul. 13, 2022, 3:58 p.m. MehStrongBadMeh, ***@***.***> wrote: @yshui <https://github.com/yshui> I am no longer convinced the issue is related to m3u8. Although I also have no idea what is going on. I tried the example RTSP stream on this page: https://www.wowza.com/developer/rtsp-stream-test but it failed to play in Proton (works fine in Windows). We'll be releasing the update pretty soon, so you'll have an opportunity to try it out for yourself and see what is going on. Sidenote: one of my co-workers mentioned that most of our users who set up RTSP streams actually use RTSPT, which was left out of the added scheme handlers for some reason. — Reply to this email directly, view it on GitHub <#1199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQNHWT5FEI3PMXDQH56WJ3VT4NVTANCNFSM4FS34H6A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MehStrongBadMeh]

Anyone else reading this thread. Don't let Lhun discourage you from adding rtspt support to the scheme handlers.

[ZarathustraDK]

Also getting the freezing issue here on proton experimental. It was definitely there in the previous experimental version also, since I remember it freezing there too while testing the video-fixes.

[Lhun]

Anyone else reading this thread. Don't let Lhun discourage you from adding rtspt support to the scheme handlers.

I'm not sure where you thought I was discouraging anyone, i'm saying precicely the opposate. RTSPT followed by HLS m3u8 in h.264 main@4.1 in that order, everything else is fairly miniscule. You need all three! RTSPT is the -most- required protocol encapsulation and delivery if you want the "full monty" vrchat clubbing experience on linux with low latency, like it is for windows.
I hope it's available soon, because i've got plenty of people who would jump to linux full time if that one thing worked (myself included, probably!)

[alasky17]

@ZarathustraDK @happysmash27 @Goofybud16 We are currently looking into the experimental freeze. My recommendation is to use PROTON_NO_FSYNC=1 %command% for now while we work on solving the problem.

We have been having trouble reproducing the issue -- could y'all get logs of the freeze? You can just add this to the launch options (without nofsync of course): PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%

[MehStrongBadMeh]

That actually cropped up when I had QA test the updated AVPro (to ensure we were clear to merge it into the codebase). Seems to be totally random, though it strikes more commonly on a fresh install of VRChat, so it may be worth uninstalling and reinstalling VRChat to try to bait it out.

[yshui]

VRChat also seem to trigger a bug in Wine, see: #1199 (comment) Hope this can get some attention...

I said it went away with wiping compdata. This is true to some extent, before I did that, VRChat crashes so often it's unplayable. Now it still happens but it way less often, maybe once every 30 hours of play time?

[alasky17]

@Goofybud16

Experimental 20220628 Unset Perfectly fine for 20-30 minutes
Experimental 1 Works for hours, no problems
Experimental Bleeding Edge 1 Runs fine for 20-30 minutes

Could you clarify what you mean here? Did you have trouble with either build after 20-30 min? Or did you just only test those proton versions for 20-30 min whereas you tested the other version for many hours? If there is a problem after 20-30 min, a log with just PROTON_LOG=1 of that problem would be helpful.

Also, logs of the freeze with the logging channels I mentioned above (PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%) would be greatly appreciated if you get time :)

[Goofybud16]

Did you have trouble with either build after 20-30 min?

No issues, to clarify, that is just how long I ran them for before moving on. The one I tested for hours is my usual play configuration.

I further tested Experimental Bleeding Edge after that comment for a few hours, and it seems to hold up find as well with PROTON_NO_FSYNC=1.

20220628 build also ran fine back when I was using it (before it updated) but I didn't test it for a longer period this time.

[happysmash27]

My VRChat logs with PROTON_LOG=1 often have a series of base-64-esque characters, a newline, then a string beginning with authcookie_ that contains a series of numbers and characters delineated by - afterwards. Are logs with these safe to publish publicly, or should one remove any lines containing these beforehand?

[happysmash27]

@ZarathustraDK @happysmash27 @Goofybud16 We are currently looking into the experimental freeze. My recommendation is to use PROTON_NO_FSYNC=1 %command% for now while we work on solving the problem.

We have been having trouble reproducing the issue -- could y'all get logs of the freeze? You can just add this to the launch options (without nofsync of course): PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%

Attached is my Proton log from last night with PROTON_LOG=1 which I generally leave on, passed through |grep -v "Windows.System.DispatcherQueue"|grep -v "authcookie_"|grep -v "<that random string of characters>". The random string of characters then string starting with "authcookie" seems to always start after the message that starts with <Transmtn.Get GET and which ends with something it is trying to retrieve, e.g, api/1/auth/user/notifications?type=friendRequest&n=100&offset=0, and then a >.

Since your log command includes unwind I have opted to not include the grep -v "trace:unwind", which raises the file size from 260K to 8.4M. Removing the redundant dispatcher queue messages (and authcookie things) lowered the size from 27M to 8.4M.

Since I was only running it to test an avatar and it only worked for a bit before crashing the file size is quite a bit more reasonable than normal so can be uploaded to Github without issue:

steam-438100_2_no_dispatch_queue_etc.log

It should be noted that what caused it to quit fully was most likely me closings SteamVR, after the freeze lasted long enough that it did not look like it would recover.

I will also use the requested log options in the future, but in case it is of any use I am sending a currently available log now in order to get a log out more quickly.

[gofman]

Please mind that logs are compressed very well, even a several GB log can be compressed and uploaded somewhere. Unfortunately the basic log gives no clue what it is waiting for, chances are that the log with suggested channels will tell more.

[gofman]

Also, is it possible to check if the hang is there or not with PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 (that is, with server sync)?

[gofman]

Also, I actually do see something in the log, the game is probably hung in its main thread while holding a ctitical section from GameAssembly.dll (no clue why though). If it is maybe possible to guess from some game logs what it is waiting for maybe it can give some clue what is going wrong.

[guerryer]

#1199 (comment) @alasky17
Here's a log of VRChat after it crashed
steam-438100.zip

[happysmash27]

I was finally able to get a freeze log after many tries, but my log is 52MB even after compression and cannot be uploaded because of that. And the crazy thing, is that this is one of my smallest logs! I had tried doing the same thing earlier but just didn't crash for so long, and ended up with a log of 50GB or so before I restarted VRChat without the logging. This logging format uses data like crazy enough to tank my framerate, so I couldn't just leave it on all the time... but then VRChat started crashing again so I was able to get it to happen shortly after launch and capture it in the log, which again, is still too big for Github.

[happysmash27]

VRChat is implementing EAC. @MehStrongBadMeh, has the checkbox that makes it work on Linux been checked? Worried that I may get banned despite not using any mods.

[happysmash27]

Also wonder if this effects YouTube-DL or not. I had swapped it out before and would need to double-check it is original if it is doing EAC on YouTube-DL too.

[MehStrongBadMeh]

I have ensured and tested that EAC has been set to be Linux, Proton, and Steam Deck compatible. No worries there.

[gofman]

I was finally able to get a freeze log after many tries, but my log is 52MB even after compression and cannot be uploaded because of that. And the crazy thing, is that this is one of my smallest logs! I had tried doing the same thing earlier but just didn't crash for so long, and ended up with a log of 50GB or so before I restarted VRChat without the logging. This logging format uses data like crazy enough to tank my framerate, so I couldn't just leave it on all the time... but then VRChat started crashing again so I was able to get it to happen shortly after launch and capture it in the log, which again, is still too big for Github.

There should be a way to upload 52MB somewhere. E. g., dropbox?