V1.20 version can only open one device window when multiple devices are connected. #2779
Comments
The startup command is: scrcpy -s serial number. |
|
Could not reproduce. Could you please copy-paste the exact command you execute and the whole console output? |
First device D:\scrcpy-win64-v1.20>scrcpy -s 66J5T19614020092 Second device D:\scrcpy-win64-v1.20>scrcpy -s e2b16c The second device cannot display the projection window, and the device will light up. |
|
Does it work if there is only one device connected? Does the second device work with scrcpy v1.19? |
V1.19 includes the previous version and everything is normal. You can also test multiple devices on windows. |
It is found that regardless of whether it is multiple devices or the same device, only one window can be opened in the V1.20 version, and the V1.19 version does not have this problem. |
|
It seems you are not alone having this kind of problem with a secondary scrcpy instance with v1.20: #2778 (comment) However, I fail to reproduce. Is it over USB or wifi? Could you try opening two instances for a device connected via wifi? |
I did not use VBS to start, but directly entered scrcpy -s in the console to specify the device to start. Whether it is wired, wireless, multiple device connection, or single device connection, I can always start only one scrcpy window, and start the other will be stuck. The corresponding window will not appear. In V1.19 and earlier versions, multiple device windows can be opened at the same time. |
|
Hmm… I really fail to reproduce, either with one device opened twice, or two devices open once, I can always open multiple scrcpy window instances with v1.20. I will continue to try to reproduce, but if you get any additional info, please share :) (You run the two instances of scrcpy from two separate terminals, correct?) |
Yes, I run it from two different terminals. |
Start a device in a terminal, and then open a terminal to start other devices. The first device to start can open the window normally, and the other consoles will be stuck and no error message is generated. |
I just did exactly this, and both device windows are correctly open. Could you run with |
After one terminal is started, the other terminal will only display these. |
The terminal that starts normally is displayed like this. |
Oh, interesting. When this happens, is there something interesting in |
|
OK, let's try to add more logs: diffdiff --git a/app/src/adb_tunnel.c b/app/src/adb_tunnel.c
index f02eb83e..d5f635f0 100644
--- a/app/src/adb_tunnel.c
+++ b/app/src/adb_tunnel.c
@@ -25,6 +25,7 @@ disable_tunnel_reverse(struct sc_intr *intr, const char *serial) {
static bool
enable_tunnel_forward(struct sc_intr *intr, const char *serial,
uint16_t local_port) {
+ LOGI("=== adb forward: %s %d", serial, (int) local_port);
sc_pid pid = adb_forward(serial, local_port, SC_SOCKET_NAME);
return sc_process_check_success_intr(intr, pid, "adb forward");
}
@@ -32,6 +33,7 @@ enable_tunnel_forward(struct sc_intr *intr, const char *serial,
static bool
disable_tunnel_forward(struct sc_intr *intr, const char *serial,
uint16_t local_port) {
+ LOGI("=== adb forward remove: %s %d", serial, (int) local_port);
sc_pid pid = adb_forward_remove(serial, local_port);
return sc_process_check_success_intr(intr, pid, "adb forward --remove");
}
diff --git a/app/src/server.c b/app/src/server.c
index d792364d..e89b1865 100644
--- a/app/src/server.c
+++ b/app/src/server.c
@@ -342,43 +342,72 @@ sc_server_connect_to(struct sc_server *server, struct sc_server_info *info) {
sc_socket video_socket = SC_SOCKET_NONE;
sc_socket control_socket = SC_SOCKET_NONE;
if (!tunnel->forward) {
+ LOGD("=== Tunnel reverse");
+
+ LOGD("=== video_socket accept()");
video_socket = net_accept_intr(&server->intr, tunnel->server_socket);
if (video_socket == SC_SOCKET_NONE) {
+ LOGD(" --> video_socket ko");
goto fail;
}
+ LOGD(" --> video_socket ok");
+ LOGD("=== control_socket accept()");
control_socket = net_accept_intr(&server->intr, tunnel->server_socket);
if (control_socket == SC_SOCKET_NONE) {
+ LOGD(" --> control_socket ko");
goto fail;
}
+ LOGD(" --> control_socket ok");
} else {
+ LOGD("=== Tunnel forward");
+
uint32_t attempts = 100;
sc_tick delay = SC_TICK_FROM_MS(100);
+ LOGD("=== video_socket connect_to_server()");
video_socket = connect_to_server(server, attempts, delay);
if (video_socket == SC_SOCKET_NONE) {
+ LOGD(" --> video_socket ko");
goto fail;
}
+ LOGD(" --> video_socket ok");
// we know that the device is listening, we don't need several attempts
control_socket = net_socket();
if (control_socket == SC_SOCKET_NONE) {
+ LOGD(" control_socket net_socket() failed");
goto fail;
}
+ LOGD("=== control_socket connect()");
bool ok = net_connect_intr(&server->intr, control_socket,
IPV4_LOCALHOST, tunnel->local_port);
if (!ok) {
+ LOGD(" --> control_socket ko");
goto fail;
}
+ LOGD(" --> control_socket ok");
}
+ LOGD("=== Close adb tunnel");
// we don't need the adb tunnel anymore
sc_adb_tunnel_close(tunnel, &server->intr, serial);
// The sockets will be closed on stop if device_read_info() fails
+ LOGD("=== Device read info");
bool ok = device_read_info(&server->intr, video_socket, info);
if (!ok) {
+ LOGD(" --> device read info ko");
goto fail;
}
+ LOGD(" --> device info: [%s] %ux%u", info->device_name,
+ info->frame_size.width, info->frame_size.height);
+
+ if (video_socket == SC_SOCKET_NONE) {
+ LOGD("video_socket not initialized");
+ }
+ if (control_socket == SC_SOCKET_NONE) {
+ LOGD("control_socket not initialized");
+ }
assert(video_socket != SC_SOCKET_NONE);
assert(control_socket != SC_SOCKET_NONE);
@@ -389,6 +418,7 @@ sc_server_connect_to(struct sc_server *server, struct sc_server_info *info) {
return true;
fail:
+ LOGD(" server_connect_to goto fail");
if (video_socket != SC_SOCKET_NONE) {
if (!net_close(video_socket)) {
LOGW("Could not close video socket");
@@ -439,6 +469,10 @@ run_server(void *data) {
goto error_connection_failed;
}
+ LOGD("tunnel %s %" PRIu16 "\n", server->tunnel.forward ? "forward"
+ : "reverse",
+ server->tunnel.local_port);
+
// server will connect to our server socket
sc_pid pid = execute_server(server, params);
if (pid == SC_PROCESS_NONE) {
diff --git a/app/src/util/intr.c b/app/src/util/intr.c
index 50d9abbe..5f41acd5 100644
--- a/app/src/util/intr.c
+++ b/app/src/util/intr.c
@@ -54,6 +54,7 @@ void
sc_intr_interrupt(struct sc_intr *intr) {
sc_mutex_lock(&intr->mutex);
+ LOGD("Interrupt");
atomic_store_explicit(&intr->interrupted, true, memory_order_relaxed);
// No more than one component to interrupt
diff --git a/server/src/main/java/com/genymobile/scrcpy/Server.java b/server/src/main/java/com/genymobile/scrcpy/Server.java
index fdd9db88..db883416 100644
--- a/server/src/main/java/com/genymobile/scrcpy/Server.java
+++ b/server/src/main/java/com/genymobile/scrcpy/Server.java
@@ -99,6 +99,7 @@ public final class Server {
try {
controller.control();
} catch (IOException e) {
+ e.printStackTrace();
// this is expected on close
Ln.d("Controller stopped");
}
@@ -115,6 +116,7 @@ public final class Server {
try {
sender.loop();
} catch (IOException | InterruptedException e) {
+ e.printStackTrace();
// this is expected on close
Ln.d("Device message sender stopped");
}Replace these binaries in your v1.20 release:
Then reproduce the issue, and post:
|
Console output adb log |
|
Thank you. Could you also post the console output of the first scrcpy (which works)? Could you please also do the same test with |
|
Oh it seems it happens only with |
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. One possibility could be to use an extended API to set extra attributes on process creation: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> But it seems that this API is not available on MinGW (it does not compile). As an alternative, explicitly mark all sockets as non-inheritable. Fixes #2779 <#2779>
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. One possibility could be to use an extended API to set extra attributes on process creation: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> But it seems that this API is not available on MinGW (it does not compile). As an alternative, explicitly mark all sockets as non-inheritable. Fixes #2779 <#2779>
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket is inherited by the process running adb to execute the server on the device, so it may not be closed properly, causing other instances of scrcpy to fail. To fix the issue, use an extended API to explicitly set the HANDLE to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779>
|
Please test #2783. |
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket is inherited by the process running adb to execute the server on the device, so it may not be closed properly, causing other scrcpy instances to fail. To fix the issue, use an extended API to explicitly set the HANDLE to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779>
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket is inherited by the process running adb to execute the server on the device, so it may not be closed properly, causing other scrcpy instances to fail. To fix the issue, use an extended API to explicitly set the HANDLE to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779>
It can work normally, thank you! |
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket is inherited by the process running adb to execute the server on the device, so it may not be closed properly, causing other scrcpy instances to fail. To fix the issue, use an extended API to explicitly set the HANDLE to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779>
|
@Helaer Thank you 👍 (just to be sure, you tested with the latest binaries I updated just before I posted the comment 15 minutes ago, not the previous ones) |
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket was inherited by the process running adb to execute the server on the device, so it could not be closed properly, causing other scrcpy instances to fail. To fix the issue, use an extended API to explicitly set the HANDLEs to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779>
To be able to communicate with a child process via stdin, stdout and stderr, the CreateProcess() parameter bInheritHandles must be set to TRUE. But this causes *all* handles to be inherited, including sockets. As a result, the server socket was inherited by the process running adb to execute the server on the device, so it could not be closed properly, causing other scrcpy instances to fail. To fix the issue, use an extended API to explicitly set the HANDLEs to inherit: - <https://stackoverflow.com/a/28185363/1987178> - <https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873> Fixes #2779 <#2779> PR #2783 <#2783>
|
Thanks! Fixed by #2783 then, I'm closing. |
V1.20 version can only open one device window when multiple devices are connected, and the computer system is windows10.
The text was updated successfully, but these errors were encountered: