Observed during both automatic reconnect and handoff testing: the daemon logs scrcpy launched for , and the scrcpy process appears in Task Manager, but no mirror window is ever shown. A few seconds later, the process exits as the device transitions to offline.
With automatic reconnect, this results in a loop:
Device reconnects successfully.
scrcpy is launched.
No window ever appears.
Device goes offline.
scrcpy exits.
The reconnect cycle repeats.
This appears to be closely related to #3, where the daemon may be acting on a connection before it has fully stabilized. Both the automatic reconnect path (WirelessReconnector → onReady() → auto-launch) and the manual handoff path eventually reach the same launch logic, so the debounce fix from #3 may resolve this as well.
Action: Re-test after the debounce changes land before investigating further. If the issue still occurs, the daemon currently has no reliable way to determine whether scrcpy has merely started or has actually established a successful mirroring session. A proper success signal (for example, monitoring scrcpy's stdout for a message indicating that the connection is fully established) would likely be needed instead of assuming process startup implies success.
Observed during both automatic reconnect and handoff testing: the daemon logs scrcpy launched for , and the scrcpy process appears in Task Manager, but no mirror window is ever shown. A few seconds later, the process exits as the device transitions to offline.
With automatic reconnect, this results in a loop:
Device reconnects successfully.
scrcpy is launched.
No window ever appears.
Device goes offline.
scrcpy exits.
The reconnect cycle repeats.
This appears to be closely related to #3, where the daemon may be acting on a connection before it has fully stabilized. Both the automatic reconnect path (WirelessReconnector → onReady() → auto-launch) and the manual handoff path eventually reach the same launch logic, so the debounce fix from #3 may resolve this as well.
Action: Re-test after the debounce changes land before investigating further. If the issue still occurs, the daemon currently has no reliable way to determine whether scrcpy has merely started or has actually established a successful mirroring session. A proper success signal (for example, monitoring scrcpy's stdout for a message indicating that the connection is fully established) would likely be needed instead of assuming process startup implies success.