search

Xiexe / XSOverlay-Issue-Tracker

This is a public repository for tracking issues with XSOverlay. There will be no other activity here other than bug reports / feature requests.
10 stars 4 forks source link

Overlay window stops updating after a while #295

Open mfboulos opened 8 months ago

mfboulos commented 8 months ago

Describe the bug in detail: I use a single, hand tracked, locked, autohidden, window in VR. When loading XSOverlay, I load that window from a preset, resize it, and leave it. I click it maybe once or twice in a several hour session, and bring up the SteamVR dashboard often.

The issue is, at some point the window stops updating, but continues to accept inputs (verifiable by looking at the desktop through SteamVR dash after input). The only workaround is to restart XSOverlay, but within the past couple weeks it hasn't lasted for more than an hour. I've been testing different ways to reproduce it, but I can't figure out a definitive cause apart from potentially SteamVR dashboard desktop interaction?

Provide steps to reproduce the bug: Steps to reproduce the behavior:

  1. Open an overlay window
  2. Open a VR application (ex: VRChat)
  3. Frequently open and close SteamVR dashboard, interact with desktop windows, or wait 30m-1hr
  4. Click on overlay window (verify when it does not update)

Expected behavior: What do you expect to happen, rather than what does happen? I expect the window to continue updating. With this issue, it visually freezes, despite the window still being interactable

Output Log: Short session with XSOverlay restart

Long session without XSOverlay restart

Additional Information: Provide any additional information here.

Nekobot-xpto commented 8 months ago

I have been having this issue as well.

There does not seem to be a clear guaranteed reproduction of the bug, other than time.

The wrist overlay and associated menus seem unaffected by this issue. Spawned overlays, however, are impacted. It seems that the overlay just stops updating\drawing, but I can still interact with the window. Destroying and recreating the overlay does not seem to fix the issue. The only guaranteed fix is restarting XSOverlay. Additionally, when this issue does trigger, it applies to all spawned overlays, not just a single window.

Output log from when this most recently happened: output_log_2023-10-20__00.19.32.txt

Xiexe commented 8 months ago

There will be a rather large update coming out tomorrow.

While there isn't any guarantee that it will fix this problem entirely, it does seem to have improved over the course of the beta.

This is a known problem and unfortunately I've yet to figure out the cause -- as you've said, there isn't a known way to reproduce it, and it's not an issue I've ever been able to reproduce locally.

All I'm able to do for now is take shots in the dark and hope that if there are any remaining problems with this that my analytics/error reporting will pick it up. (I added that in the beta, please leave it enabled so that I actually get to capture the crashes properly!)

Hopefully the update just resolves the issues though.

mfboulos commented 8 months ago

Update: started using the beta this time. Instead of freezing, the whole overlay (wrist, window, and all) disappears, with XSOverlay still running. Tried double tapping A buttons to bring up the menu, no dice. Happened once, restarted XSOverlay, happened again in the same session, both times within half an hour or so.

Logs: First Second

Xiexe commented 8 months ago

The logs are showing normal operations, which means I won't be able to do much until more information has been gathered on the issue.

If you can find a way to reproduce it other than "wait x time" that would be good, as I've left the overlay open for an 24 hours during testing without having this happen.

Nekobot-xpto commented 8 months ago

I just wanted to follow up. Since the updates, I haven't experienced any update issues for overlays updates so far.

mfboulos commented 7 months ago

Update: I've been debugging further by adding settings one by one. Earlier today I ran an entire session without crashing with the following sequence:

I'm convinced the issue is somewhere in the autohide. Nekobot hit an issue with her overlay freezing semi-transparent with autohide enabled. It's possible my windows are there, but not reappearing.

Xiexe commented 7 months ago

Update: I've been debugging further by adding settings one by one. Earlier today I ran an entire session without crashing with the following sequence:

  • Create a window with default settings (world space)

  • Wait

  • Lock it to the left hand

  • Resize it down and reposition

  • Wait

  • Pin the window

  • Wait

I'm convinced the issue is somewhere in the autohide. Nekobot hit an issue with her overlay freezing semi-transparent with autohide enabled. It's possible my windows are there, but not reappearing.

I'll take a look at the autohide stuff and see. It's always possible there's a race condition that was introduced recently.

mfboulos commented 4 months ago

Update: tested again yesterday, bug still persists. It is 100% still an autohide issue, and I have to work around it by disabling autohide or else the overlay will break less than an hour into a session. Logs don't show anything unusual since overlay creation.