Bug Symptoms
Running the app and the Playnite plugin together, one of the Playnite connector components gets locked out of the named pipe by its sibling components and falls into a tight reconnect loop. On my machine the plugin logged ~440 PipeServer: connection failed errors per second for ~66 s, producing an 11.2 MB log file (58,341 identical error lines of 116,686 total). The loop ran until the app shut down.
One session (2026-10-30, 11:59:07 – 12:00:16) produced four sibling sunshine_playnite-*.log files showing three concurrent connector components:
sunshine_playnite-20261030-115908-270.log— in-Playnite plugin (V2 UI bridge): connected, sent the full snapshot (1091 games), worked.sunshine_playnite-20261030-115909-997.log— connector process ("Outbox bound to existing global singleton", "activating Sunshine connection"): connected, sent snapshot, worked.sunshine_playnite-20261030-115910-008.log— the[PipeServer]component: loggedPipeServer: Sunshine core connection readyonce, then every subsequent connection attempt failed with:
[2026-10-30 11:59:10.171] [ERROR] [PipeServer] PipeServer: connection failed: Exception calling .ctor with 8 argument(s): Wszystkie wystąpienia potoku są zajęte.(= .NET System.IO.IOException "All pipe instances are in use", localized to Polish; the .ctor wording is PowerShell's 8-argument NamedPipeClientStream constructor.) ~29k failed attempts in 66 s, sub-millisecond cadence, no backoff visible in the log.
Related reports (same/adjacent symptoms): #677 (same error flood on 2.0.2-d20261025, plus 12–15% CPU increase involving Playnite and Windows Defender), #618 (connector flaps between Connected/Limited), #608.
Expected Behavior
All connector components should be able to use the pipe without starving each other; at the very least, connection failures should be bounded/backed off, so a busy pipe produces a single "retrying in N s" line instead of ~440 error lines per second and multi-MB log files.
Root-cause pointer
plugins/playnite/SunshinePlaynite/src/ConnectorPipeTransport.cs, CreateServer():
return new NamedPipeServerStream(name, PipeDirection.InOut, 1, PipeTransmissionMode.Byte, options, 65536, 65536, security);maxNumberOfServerInstances = 1. While one client holds the only instance, every other connector component's connection attempt fails immediately with ERROR_PIPE_BUSY ("All pipe instances are in use"), and the [PipeServer] component retries in a tight loop without backoff.
Windows Version
26H2 (10.0.26300) — not present in the template dropdown
Package
Windows - exe installer
GPU Type
NVIDIA
GPU Model
NVIDIA GeForce RTX 5090
GPU Driver Version
621.01
Capture Method
Unknown (not relevant to this bug — it occurs while the app is idle, no active stream)
Apps
n/a
Logs (Optional but Recommended)
Excerpt from sunshine_playnite-20261030-115910-008.log (window 11:59:10 → 12:00:16, 11.2 MB total):
[2026-10-30 11:59:10.001] [INFO] [T#22 RS=82b742e7] Outbox bound to existing global singleton
[2026-10-30 11:59:10.002] [INFO] [T#22 RS=82b742e7] [PipeServer] PipeServer: starting
[2026-10-30 11:59:10.163] [INFO] [T#22 RS=82b742e7] [PipeServer] PipeServer: Sunshine core connection ready
[2026-10-30 11:59:10.171] [ERROR] [PipeServer] PipeServer: connection failed: Exception calling .ctor with 8 argument(s): Wszystkie wystąpienia potoku są zajęte.
[2026-10-30 11:59:10.174] [ERROR] [PipeServer] PipeServer: connection failed: Exception calling .ctor with 8 argument(s): Wszystkie wystąpienia potoku są zajęte.
[2026-10-30 11:59:10.177] [ERROR] [PipeServer] PipeServer: connection failed: Exception calling .ctor with 8 argument(s): Wszystkie wystąpienia potoku są zajęte.
... (repeats ~440 times per second for 66 s; 58,341 identical ERROR lines) ...
[2026-10-30 12:00:16.682] [ERROR] [PipeServer] PipeServer: connection failed: Exception calling .ctor with 8 argument(s): Wszystkie wystąpienia potoku są zajęte.
[2026-10-30 12:00:16.682] [INFO] [T#22 RS=82b742e7] [Reader] Reader: EOF from Sunshine core
[2026-10-30 12:00:16.684] [INFO] [T#22 RS=82b742e7] [Connector loop] Connector loop: exiting (stopping=True)Full logs on Gist (4 files — this log plus the 3 sibling logs from the same session): https://gist.github.com/brx19/a8bbceb3d719dbdd1beee3ff16bf2979
Version: Vibepollo 2.0.2-nightly.d20261026.r.1.e3d13d104c0b (installed as "Apollo", C:\Program Files\Apollo).
Screenshot (Optional)
n/a
Activity
6
Nonary8d agoThe supplied startup logs show both the compiled connector and the older PowerShell connector loading. The high-rate [PipeServer] constructor failures come from the PowerShell connector. #689 adds retry backoff to the compiled connector and host, but cannot change a retained PowerShell module; the reported October 26 build also predates that change.
Could you share the connector extension paths under Playnite's application and configuration folders, and the loaded extension files (SunshinePlaynite.psm1, SunshinePlaynite.dll, and extension.yaml)? After updating the host and reinstalling its bundled connector, please include the resulting startup logs. The manifest version alone may not identify the deployed DLL.
The single-instance pipe is a rendezvous endpoint; accepted connections move to separate data pipes, so increasing that limit is not yet an established fix.
brx198d agoBoth connectors are in fact deployed side by side — found the older one; it sits in the Playnite install directory, not the config folder.
Paths
| What | Path |
|---|---|
| Playnite install (app folder), v10.63 | D:\Games\Playnite\ |
Older PowerShell connector (v0.4.12, Id Sunshine.Playnite.PowerShell, Type Script, file date 2026-07-29) | D:\Games\Playnite\Extensions\SunshinePlaynite\ — extension.yaml + SunshinePlaynite.psm1 |
Compiled connector (v0.5.2, Id Sunshine.Playnite.Integration, file date 2026-10-26 11:40) | C:\Users\BrX\AppData\Roaming\Playnite\Extensions\SunshinePlaynite\ — extension.yaml + VibepolloPlaynite.dll |
| Data dir for the old PowerShell extension (empty) | C:\Users\BrX\AppData\Roaming\Playnite\ExtensionsData\Sunshine.Playnite.PowerShell\ |
| Host-bundled connector (byte-identical to the deployed DLL) | C:\Program Files\Apollo\plugins\playnite\SunshinePlaynite\ |
Files — both extension.yaml files and the full SunshinePlaynite.psm1 (99,794 B) are in this Gist, with a README of paths/hashes: https://gist.github.com/brx19/763e356bfa4b104921d30f6a9314b72d
SunshinePlaynite.psm1SHA-2564ccac66591c99dc2be93302e45ce36eb19795cd1c1fdd2427d9ba47bcec3b831VibepolloPlaynite.dll(53,760 B) SHA-256c9e8a15e14532c3cd8e0d49135f28b56d4e539328f59a84035d15f6f71cfb513, ProductVersion0.5.2+e3d13d104c0b7f4af1d0a3dad156a3e3c7d1bc44— matches the installed host2.0.2-nightly.d20261026.r.1.e3d13d104c0b. The deployed copy and the host-bundled copy are identical.- The DLL has no .NET manifest resources (only VS_VERSION_INFO), so the PowerShell module is not embedded in it; it loads from the install-dir path above.
Flood source confirmed in the psm1 — Start-PipeServerLoop (line 1162): builds the 8-arg NamedPipeServerStream for Sunshine.PlayniteExtension (line 1172, single instance), and on any exception logs PipeServer: connection failed (line 1232) and immediately re-enters the while loop — no backoff in this version, which is where the ~440/s loop comes from. The exact log lines map to psm1 lines 903 / 1005 / 1165 / 1232.
Agreed on the rendezvous-point model; the single-instance limit increase is not a proposed fix — the ask here is just the missing backoff/quiet-retry in the PowerShell path, since this 0.4.12 module predates #689.
Nonary8d agoConfirmed: the supplied SunshinePlaynite.psm1 is 99,794 bytes with the SHA-256 you reported. After normalizing only the BOM/line endings, it matches the historical July source. Start-PipeServerLoop logs the constructor exception at line 1232 and immediately retries; there is no backoff on that path. Your narrowed diagnosis is correct.
That script was retired when the connector moved to the compiled plugin. #689 changes the compiled connector and host, not the old script left in another extension root. The current installer removes obsolete files within its selected destination, which can leave a legacy copy in the other root. Adding backoff to the retired script would reduce the flood but leave both connectors competing.
For a reversible isolation step, disable only Sunshine.Playnite.PowerShell (the old “Sunshine Playnite Connector”), leaving Sunshine.Playnite.Integration / “Vibepollo Playnite Connector” enabled. Playnite documents extension disabling under Add-ons → Installed. Fully exit and restart Playnite afterward; disabling without restarting may leave the existing runspaces alive. No file deletion is needed.
Please attach the fresh startup logs after that restart, with the host build and deployed connector version. That will show whether the legacy flood is gone and whether any compiled-only problem remains; this is not yet a confirmed fix.
brx198d agoRemoving the old retired script solved the problem, but Update/Upgrade should check both paths in my opinion, as I was not aware that there can be multiple of them in different places.
Nonary8d agoThanks for confirming that removing the retired PowerShell connector resolved the flood on your setup. That is consistent with the immediate-retry path in the supplied script and the two connectors competing for the same rendezvous pipe.
The upgrade-prevention concern remains: cleanup is currently scoped to the selected extension destination, so a legacy connector in the other Playnite extension root can survive. A safe migration needs to identify the roots belonging to the same Playnite installation and verify the old connector before retiring it, rather than blindly removing folders from both locations.
Keeping this issue open for that installer/migration gap. Your recovery confirmation is useful; no need to repeat the isolation steps or provide more logs just to confirm that recovery.
Full session logs (Gist, 4 files):
sunshine_playnite-20261030-115910-008.en.log(the 11.2 MB one from the issue) plus the 3 sibling logs from the same 2026-10-30 session. The.en.logcopies are the originals with only the Polish-localized .NET message translated to English ("All pipe instances are in use."); every other byte is unchanged. https://gist.github.com/brx19/a8bbceb3d719dbdd1beee3ff16bf2979