Bug Report Game Capture Incorrect Target Conflict

[FerretBomb]

This has been an issue for a while; as Game Capture appears to re-hook each time you switch scenes, it will occasionally grab the wrong process (even when set to Match Exact). Here's a Clip of it happening during a live broadcast earlier today:

Twitch

Twitch is the world's leading video platform and community for gamers.

clips.twitch.tv

This is switching from a scene with one Game Capture (primary game, Nova Drift) to a second scene with a different Game Capture (Stream Raiders). The GC processes got 'confused' on the re-hook, and the GC pointed at StreamRaiders continued to show the hook from Nova Drift. This used to happen all the time with a realtime video generation software suite. It still happens in this case, but only rarely.

The second-scene GC showed itself as pointing at the StreamRaiders process, but continued to show Nova Drift on the source properties preview until I re-pointed it at the Nova Drift executable, at which point StreamRaiders popped up. Re-pointing it at StreamRaiders fixed the conflict.
This only happens erratically/occasionally, but it DOES still happen. The processes are named NovaDrift.exe and StreamRaiders.exe so it isn't a process-name confusion issue (as can happen with Osu!). The logfile (excerpted below) shows that the "GC - StreamRaiders" source says it's capturing StreamRaiders.exe, but on-stream it definitely did NOT. The following 'attempting to hook process NovaDrift.exe' for that source was me opening the source properties and selecting ND (at which point SR came up) and then pointing it back at SR. I've included pre and post lines for context, and have annotated the relevant lines

08:41:44.111: [game-capture: 'GC - Global Hotkey'] attempting to hook process: NovaDrift.exe
08:41:44.123: User switched to scene '(5) MainGame'
08:41:44.125: [game-capture: 'GC - Global Hotkey'] shared texture capture successful
08:41:44.459: [game-capture: 'GC - StreamRaiders'] capture stopped
08:51:59.248: [game-capture: 'GC - Global Hotkey'] d3d11 shared texture capture successful
08:51:59.258: [game-capture: 'GC - Global Hotkey'] shared texture capture successful
09:01:35.360: [game-capture: 'GC - StreamRaiders'] attempting to hook process: StreamRaiders.exe (edit: this is the mis-hook occurring)
09:01:35.365: User switched to scene 'StreamRaiders'
09:01:35.375: [game-capture: 'GC - StreamRaiders'] shared texture capture successful
09:01:38.342: warning: Could not update timestamps for discarded samples.
09:01:38.925: [game-capture: 'GC - Global Hotkey'] capture stopped
09:02:02.375: [game-capture: 'GC - StreamRaiders'] capture stopped
09:02:02.377: [game-capture: 'GC - StreamRaiders'] attempting to hook process: NovaDrift.exe (edit: this is me changing the Source target, which showed SR)
09:02:02.391: [game-capture: 'GC - StreamRaiders'] shared texture capture successful
09:02:06.625: [game-capture: 'GC - StreamRaiders'] capture stopped
09:02:06.627: [game-capture: 'GC - StreamRaiders'] attempting to hook process: StreamRaiders.exe (edit: this is me changing it back to SR, which stayed on-screen)
09:02:06.641: [game-capture: 'GC - StreamRaiders'] shared texture capture successful
09:03:14.210: [game-capture: 'GC - Global Hotkey'] attempting to hook process: NovaDrift.exe
09:03:14.225: [game-capture: 'GC - Global Hotkey'] shared texture capture successful
09:03:14.227: User switched to scene '(5) MainGame'
09:03:14.575: [game-capture: 'GC - StreamRaiders'] capture stopped
09:09:28.116: [game-capture: 'GC - Global Hotkey'] d3d11 shared texture capture successful
09:09:28.125: [game-capture: 'GC - Global Hotkey'] shared texture capture successful

This isn't a performance issue. This is GameCapture grabbing the wrong source entirely, when a scene set has multiple GCs in it, even if the GCs are in completely separate scenes. Transition in-use was a Stinger, if that has any bearing on the problem (as Stingers appear to have other issues still).

 

[FerretBomb]

Issue reoccurred today. Swapping scenes again caused the issue to be fixed. Are GCs really kept running in the background? I'd expect this might happen if the GC was shut down every time the scene was switched, and if the new one on the destination scene grabbed the existing 'handle' for the current-scene hook which hadn't finished shutting down yet.

Twitch

Twitch is the world's leading video platform and community for gamers.

clips.twitch.tv

Again, I've been told that the GCs don't actually shut down and re-hook each time you leave/arrive on a scene with one, despite the logfile entries. If that's the case, what's going on here? Also, no idea whatsoever why it was flipped and mirrored this time.

 

[Narcogen]

It's generally recommended to use only one game capture at a time. The safest method would be to have them in separate scene collections. If you have them in the same scene collection, but in different scenes, I wouldn't necessarily have expected a problem, but then again, if I did that I wouldn't be switching to a scene set up for another game unless I intended to switch to that game.

Best practice, as long as you aren't theming all your scenes on a per-game basis, is a single game capture, reconfigured on a per-game basis, so there's never a different game capture source being switched to, active or not.

 

[FerretBomb]

Multi-capture conflict is normally between DC and GC or DC and WC, and tended to be a performance thing, not a mis-target problem. Or multiple GCs trying to hook the same process (for people trying to make zoomed-in inserts the wrong way). Those are absolutely problems, and to be avoided. Two GCs in one scene pointed at different processes should not be, any more than two Window Captures in a single scene are.

This has been an issue for a while, but I was told it was fixed some time ago; likewise, that GameCaps didn't actually 'stop' when they were not showing and re-hook when swapping back to them, that the endless 'stopping capture, hooking process' in the logs on each scene swap were just logfile cruft, and the capture was never dropped and re-hooked. From this behavior I'm finding that harder to believe, along with a handful of instances of swapping away to another scene (a fullscreen webcam for example, for chat interaction), only to change back to a blank screen until the hook finally 'kicks in' a few seconds later (Nova Drift has this happen fairly often, for example).

Classic had the option to keep GameCaps active as global sources. Why does Studio apparently not?
At this point I'm going to have to have my game capture(s) in EVERY scene, hidden behind a backdrop image just to try to keep them 'alive' as a maybe-workaround.
It'll definitely clutter things up even more, and isn't an actual fix to this apparent bug. But hopefully it will actually keep the process-hooks active instead of shutting down every time I switch scenes, and starting a new hook each time I switch back, possibly choosing the wrong process to hook.

 

[Narcogen]

I'd suggest that the best practice is not having another active game capture that forces the active one to shut down, not keeping all the ones you have active so they never shut down.

I think the problem is that so many people built their setup around avoiding the profiles and scene collections features that they've now got all their eggs in one basket.

 

[FerretBomb]

In this case, it's capturing two games at the same time; the main game, and a 'side-channel' game. Unfortunately the sidechannel does not capture correctly with a Window Capture.
However, again, it was a problem with my realtime graphics generation software as well. I had to move away from that to another solution, because OBS kept grabbing the wrong GameCap back then, too.

There is no reason that two GCs should 'mis-target' like this, especially when each is set to a specific process and to match-exact, and are in two completely different scenes. Especially if the GCs "don't shut down in the background", as was claimed by one of the Devs previously.
This isn't a scene with 50 game caps for 50 different games. It's a pretty reasonable use-case. This really, really shouldn't be an issue.

At this point no devs have chimed in about the issue, I'll just open a Mantis ticket about the GameCap behavior.

 

[Narcogen]

Every single piece of advice I've seen from forum regulars and devs is that multiple game caps, or game caps combined with other full screen cap methods (display) should not be used in conjunction with each other within the same scene.

I realize you may have a legitimate use case for wanting to do that, and possibly there's either something the devs can do to enable that, or something they can explain about why it may be fine in some use cases and not in others. But I also sort of dread the idea of this being normal spreading given how common it is that people have multiple GCs, how common it is that they experience problems with that setup, and how common it is that they deny this configuration could contribute to their issues. Part of the issue is that it doesn't just straight up fail for everyone, all the time, because whatever the underlying issue is, it is not as simple as just having two GCs in a scene, it's something that is more likely to happen when that is the case.

 

[FerretBomb]

The big issue with multiple game captures is more when someone has a scene with 50 game caps, one for each game they play. That's a lot of cruft, and should be avoided.

Display Capture conflicts are pretty standard, just due to how DC operates, and can absolutely cause performance issues when included in a scene with a game capture. Or just on their own. It's why DCs are generally advised to be avoided.

And yes, it appears to be an underlying issue with how Game Capture operates. Hopefully it'll end up being addressed.