Strategic Roadmap: 13 Core Enhancements for High-Performance Home Multi-Seat Scaling

[Dani6ca-T]

Hi! First of all, thank you for this amazing project. It fills a huge gap in the open-source self-hosted streaming ecosystem, especially for setting up efficient, low-cost home gaming networks using existing hardware.

To optimize this project for flawless home use—allowing a powerful host PC to seamlessly stream to older laptops, TV boxes, or mobile devices via Moonlight without performance degradation—I have compiled an updated 13-point architectural roadmap. This version focuses strictly on OS stability, dynamic provisioning, and native Windows driver automation, completely eliminating clunky third-party audio mixers like VoiceMeeter Potato or fixed donationware cables.

---

1. Version-Independent Session Unlocker (Migration to SuperRDP)

Description

The current implementation relies on hardcoded memory offsets to patch termsrv.dll (often using old RDPWrap-like methods) to allow concurrent local sessions on Windows Pro/Home. Every monthly Windows Cumulative Update changes these offsets, breaking the multi-seat functionality and requiring manual project updates. Furthermore, the default Microsoft RDP display driver (RDPDD.dll) frequently conflicts with Apollo's capture pipeline and custom virtual displays.

Proposed Solution

1. Migration to a SuperRDP-based Pattern Architecture: Instead of relying on static RDPWrap offsets that break monthly, implement or bundle a SuperRDP-style unlocker. SuperRDP uses dynamic assembly pattern scanning (signature searching) inside termsrv.dll to find and bypass concurrent session checks in RAM at runtime. This dynamically adapts to new Windows Updates without breaking code offsets.
2. RDP Graphics Pipe Suppression: Force Windows to completely ignore standard RDP virtual monitors and route rendering strictly through the physical GPU and the project's custom Virtual Display Driver from millisecond zero via registry overrides during seat deployment:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v "fEnableWcm" /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v "fNoRemoteVideoCapture" /t REG_DWORD /d 1 /f

---

2. Automated NVENC Session Limit Patching

Description

Nvidia GeForce graphics cards carry a hardcoded hardware limitation restricting the maximum number of concurrent video encoding sessions (currently capped at 5 concurrent streams on latest drivers). When scaled to multiple simultaneous family users, an Apollo instance can fail with an explicit NV_ENC_ERR_OUT_OF_MEMORY or session starvation error if other users are recording, streaming, or running intensive encoding loops.

Proposed Solution

Integrate an automated driver patching utility (like the open-source nvidia-patch tool logic) directly into the installer or background optimization script block. The script detects the installed driver version, backs up the target encoder DLL, and dynamically patches the session limit restriction on the fly.

---

3. Dynamic Child-Process CPU Affinity Enforcement

Description

While the project successfully manages session lifecycles, it currently lacks dynamic tracking for child processes spawned inside the virtual seat session. When a user launches a heavy application or game launcher (e.g., Steam/Epic), the launcher spawns sub-processes (game.exe) that bypass the initial session core limits, leading to CPU resource starvation on the main host.

Proposed Solution

Implement a proactive process watcher inside the background service using WMI events (__InstanceCreationEvent) or Win32_Process tracking. The service should monitor any new processes spawned within the specific SessionId of the secondary seat and instantly force the target CPU affinity mask upon them, including all child processes dynamically:

Get-CimInstance Win32_Process -Filter "SessionId = $TargetSessionId" | ForEach-Object {
$proc = Get-Process -Id $_.ProcessId -ErrorAction SilentlyContinue
if ($proc) { $proc.ProcessorAffinity = $SpecificSeatCoreMask }
}

---

[vibesoftwarecoder]

Answering point by point.

1. Pattern scanning instead of fixed offsets — agreed on the problem, partly solved already.

Offsets keyed to a termsrv.dll build are fragile, and we went at it from the other side. install-prerequisites.ps1 now checks whether the installed rdpwrap.ini covers the running build. If nothing covers it, it generates the offsets locally from that machine's termsrv.dll. The generator reproduced our known-good section 20 out of 20, including the variant that needs no symbol server, so it works on a host that has just lost RDP.

That leaves the gap you identified: ours repairs when someone runs the script, while a pattern scanner repairs itself at every service start. We reviewed TermWrap, including your port and @Weetermachine's, and are not adopting either yet. A second shim doubles what we support for a gain we have not needed. If local generation fails in the field, that is the route we take.

One finding from the review worth your time: fSingleSessionPerUser is 1 on our host. Harmless under RDP Wrapper. Under TermWrap it makes mstsc reconnect an existing session instead of creating one, which would look like "seats stopped provisioning" rather than a failed install. @Weetermachine's script clears it; yours does not touch it.

2. NVENC limit patching — no.

The limit is real and we document it. But nvidia-patch modifies a signed driver DLL. Shipping it in an installer means shipping something that breaks on every driver update, sits awkwardly with NVIDIA's licence terms, and fails in ways users report to us rather than to the patch. Anyone who wants it can apply it themselves.

3. CPU affinity for child processes — interesting, not yet convincing.

The gap is real; we do not track processes a launcher spawns inside a seat. Two doubts. Pinning cores usually hurts games, because the Windows scheduler moves threads for good reasons and a fixed mask stops it. And for game streaming the contended resource is normally the GPU and the encoder, not CPU cores, so affinity would not address the starvation you describe.

A measurement would settle it: two seats streaming, with and without affinity, showing frame times on the second seat. If it helps, the case is made.

One practical note. The post says 13 points but contains 3. If the rest were trimmed in an edit, we would like to read them.

[Dani6ca-T]

Absolutely — the original roadmap was 13 points, but the discussion post was trimmed down to the first 3. I’ll restore the full 13-point roadmap and post the remaining items so we can review them properly. I’m also treating it as a roadmap rather than a list of things that must be implemented: some items may be rejected, some may need measurements first, and others may be good candidates for small, independently testable changes. The goal is to prioritize practical improvements for high-performance home multiseat scaling without forcing architectural changes where the evidence doesn’t support them. пт, 4 сент. 2026 г. в 14:06, vibesoftwarecoder ***@***.***>:

…

Answering point by point. *1. Pattern scanning instead of fixed offsets — agreed on the problem, partly solved already.* Offsets keyed to a termsrv.dll build are fragile, and we went at it from the other side. install-prerequisites.ps1 now checks whether the installed rdpwrap.ini covers the running build. If nothing covers it, it *generates the offsets locally* from that machine's termsrv.dll. The generator reproduced our known-good section 20 out of 20, including the variant that needs no symbol server, so it works on a host that has just lost RDP. That leaves the gap you identified: ours repairs when someone runs the script, while a pattern scanner repairs itself at every service start. We reviewed TermWrap, including your port and @Weetermachine <https://github.com/Weetermachine>'s, and are not adopting either yet. A second shim doubles what we support for a gain we have not needed. If local generation fails in the field, that is the route we take. One finding from the review worth your time: *fSingleSessionPerUser is 1 on our host.* Harmless under RDP Wrapper. Under TermWrap it makes mstsc reconnect an existing session instead of creating one, which would look like "seats stopped provisioning" rather than a failed install. @Weetermachine <https://github.com/Weetermachine>'s script clears it; yours does not touch it. *2. NVENC limit patching — no.* The limit is real and we document it. But nvidia-patch modifies a signed driver DLL. Shipping it in an installer means shipping something that breaks on every driver update, sits awkwardly with NVIDIA's licence terms, and fails in ways users report to us rather than to the patch. Anyone who wants it can apply it themselves. *3. CPU affinity for child processes — interesting, not yet convincing.* The gap is real; we do not track processes a launcher spawns inside a seat. Two doubts. Pinning cores usually hurts games, because the Windows scheduler moves threads for good reasons and a fixed mask stops it. And for game streaming the contended resource is normally the GPU and the encoder, not CPU cores, so affinity would not address the starvation you describe. A measurement would settle it: two seats streaming, with and without affinity, showing frame times on the second seat. If it helps, the case is made. *One practical note.* The post says 13 points but contains 3. If the rest were trimmed in an edit, we would like to read them. — Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=B4T6PZMO3GDHSLDTVDKWYND5NKO4BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSHA3DMNBQUZZGKYLTN5XKY43UMF2GKX3DNBQW4Z3FUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18286640>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4T6PZMAYAKIAI2KHAU7O2D5NKO4BAVCNFSNUABJKJSXA33TNF2G64TZHMYTCOJQHEYDCOBVGA5UI2LTMN2XG43JN5XDWMJQGMZDSNJYG2QXMAQ> . You are receiving this because you modified the open/close state.Message ID: <vibesoftwarecoder/MultiSeat/repo-discussions/7/comments/18286640@ github.com>