Concrete reproduction from clean-clone terminal testing today: repeatedly pressing w while switching between same-Wi-Fi and hotspot produced three different serials for one physical phone in a single session — the USB serial, a same-Wi-Fi ip:5555, and a separate hotspot ip:5555.
ScrcpyLauncher tracks "already running" purely by serial string, so each new serial got its own independent launch, stacking a new scrcpy instance on top of whatever was already running for that same phone under a different serial. Task Manager showed ~10 accumulated scrcpy.exe processes (idle, ~13.5MB, 0% CPU/network) after one testing session — none of them doing anything, none of them exiting on their own.
Some of the concurrent instances also produced protocol-level garbage:
ERROR: Unknown codec id 0x50697865
ERROR: Demuxer 'audio': stream disabled due to unsupported codec
ERROR: Controller error
consistent with two scrcpy sessions racing over the same underlying device connection — the losing session doesn't reliably exit, it just sits idle instead.
Proposed fix: track "does this physical phone already have an active mirror" by a stable per-device identity (not per-serial) — e.g. USB serial as the anchor, mapped forward to whatever wireless address it's currently using — so the daemon can recognize "this is the same phone" across USB and every wireless address it might appear under, and either refuse a duplicate launch or actively hand off/replace the existing one instead of stacking a new process on top.
Concrete reproduction from clean-clone terminal testing today: repeatedly pressing w while switching between same-Wi-Fi and hotspot produced three different serials for one physical phone in a single session — the USB serial, a same-Wi-Fi ip:5555, and a separate hotspot ip:5555.
ScrcpyLauncher tracks "already running" purely by serial string, so each new serial got its own independent launch, stacking a new scrcpy instance on top of whatever was already running for that same phone under a different serial. Task Manager showed ~10 accumulated scrcpy.exe processes (idle, ~13.5MB, 0% CPU/network) after one testing session — none of them doing anything, none of them exiting on their own.
Some of the concurrent instances also produced protocol-level garbage:
ERROR: Unknown codec id 0x50697865
ERROR: Demuxer 'audio': stream disabled due to unsupported codec
ERROR: Controller error
consistent with two scrcpy sessions racing over the same underlying device connection — the losing session doesn't reliably exit, it just sits idle instead.
Proposed fix: track "does this physical phone already have an active mirror" by a stable per-device identity (not per-serial) — e.g. USB serial as the anchor, mapped forward to whatever wireless address it's currently using — so the daemon can recognize "this is the same phone" across USB and every wireless address it might appear under, and either refuse a duplicate launch or actively hand off/replace the existing one instead of stacking a new process on top.