I apologize for not responding sooner. It looks from the log like the client is connecting and then immediately disconnecting. So it would seem that the IP address is correct. Is it possible that there are some firewall rules blocking some of the ports that are used here? The Gabriel architecture communicates to different ports for different services, so all of those listed in the log need to be open (even though not all of them are used between the client and the server).

There is some documentation for FaceSwap available here: https://cmusatyalab.github.io/faceswap/, thought I don't see your specific issue. If you are still having difficulty, I can speak with the author of FaceSwap to see if they have any thoughts.

In Android side, I have tryed with 2 Android Mobile Smartphones: Samsung S8 (Android 7) and Benq Aquaris M5 (Android 6), and it seems that Bq Aquaris M5 have better results because it is possible to see on server that "dummy" is devolved, maybe Android version is important.

I tryed many times to make training with different names and result is ever the same error window.Then it came back to general page and try to connect to server again.

This cognitive engine sets up an HTTP server to publish the received images. If all properly set, you should now be able to see the camera images from mobile devices by connecting to http://gabriel_ip:7070/index.html using your browser.

I have tryed it and it is working, I am able to see what the mobile device is displaying.

Is it possible that you have launched ./start_demo.sh multiple times? If you do netstat -pl does it show that something is already listening on any of those ports that faceswap is trying to listen on (8021, 9098, 9099 etc)? Maybe you just need to kill the processes that are still executing from previous attempts.

The server image starts the Faceswap backend automatically using upstart. There is no need to log-in, manually kill those processes, and restart them. Just wait until the server finishes its boot process to use the client.

I agree with Tom. From the log, port 9000 is occupied. (probably because an old faceswap process?)

I have tried to wait for 5 minutes in order that server could boot all processes and result is the same. If I login and wait for process to boot, I can see that there is many gabriel-control instantiated.Is that normal?

@MSoares 5 gabriel-control processes are not normal. It means the faceswap server failed to start, and upstart kept trying for 5 times. Can you double-check if your VM supports AVX? If not please double-check if you're using the correct image. (see https://cmusatyalab.github.io/faceswap/faq/)

To furthur debug, I suggest 1. use kill_demo.sh in FaceSwap-server/ to kill all faceswap + gabriel processes 2. command "ps -aux | grep python" shouldn't return any processes after 1. If you still see processes, use kill_demo.sh multiple times or use "kill -9 pid" to forcefully kill all remaining processes 2. turn on faceswap debug flag: FaceSwap-server/demo_config.py line 3, change to "DEBUG=True" 3. reset gabriel log by "rm /var/tmp/cloudlet/log-gabriel"

It would be helpful to include the content of /var/tmp/cloudlet/log-gabriel besides stdout

@MSoaresGabriel is the underlying communication library for faceswap. start_demo.sh starts gabriel and the demo. kill_demo.sh kills the demo app and gabriel. If you just started the VM and upstart kept trying to launch faceswap, you can use "sudo service faceswap stop" to prevent upstart from trying. And then use kill_demo.sh to make sure system is clean and use start_demo.sh to start a new demo.

From the above log, it seems that the connection was successfully established and the backend processed a few frames before crashed.

Can you provide the stdout from start_demo.sh? What's the compute power of your VM?

if I launch VM and use commands "sudo service faceswap stop", then "kill_demo.sh", it will erase all gabriel and python components once for all. After I can launch demo with "start_demo.sh" but error is the same:

@MSoaresI don't see anything wrong in the stdout nor log. I couldn't reproduce this error on my side either.

Can you turn on the faceswap debug flag (FaceSwap-server/demo_config.py line 3, change to "DEBUG=True") and post the stdout and log with debug messages? BTW, there is no need to re-create a VM every time.

I saw nothing wrong in the server log. It seemed that the client just suddenly disconnected. I launched a AWS instance using the same face swap image. Can you quickly check using your client if the same problem still occur? 52.27.88.197 is the IP. I tested with my google pixel and everything worked fine.

@MSoares I don't think 2 cores and 4 GB RAM are big enough to run the demo. Both the face detection and the DNN-based recognition in the demo are compute-intensive. The failure is probably due to the computation being so slow that the client timed out or the server run out of memory.