When we start a video recording on a server in China, the first 30 seconds of the recorded video display a white-screen. After this first 30 seconds, the recording is correct.
On another solutions with the same configuration we do not experience this issue; this happens only on a server in China.
If we empty the RAM cache, the first recording we make does not have the 30-seconds white screen; the recordings thereafter present the issue once more.
The Openvidu version is 2.20.0; Openvidu recordings version is 2.19.0-custom.
Additionally, when we start a video recording on the server in China, we have the following error (not present in other solutions we have):
Sep 27 21:30:20 localhost systemd[1]: docker-e08b6cebaa9942903914158f520c8c9d0d9bdbc6a370298629272b0d875a42d3.scope: Consumed 4.082s CPU time. Sep 27 21:30:20 localhost containerd[1234147]: time="2022-09-27T21:30:20.276672410+08:00" level=info msg="shim disconnected" id=e08b6cebaa9942903914158f520c8c9d0d9bdbc6a370298629272b0d875a42d3 Sep 27 21:30:20 localhost dockerd[594949]: time="2022-09-27T21:30:20.276765144+08:00" level=info msg="ignoring event" container=e08b6cebaa9942903914158f520c8c9d0d9bdbc6a370298629272b0d875a42d3 module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete" Sep 27 21:30:20 localhost containerd[1234147]: time="2022-09-27T21:30:20.277642671+08:00" level=error msg="copy shim log" error="read /proc/self/fd/36: file already closed"
In the container of the video recording we have the following warning (this happens on other servers as well):
Did you tried with other cloud provider in china region? This is a specific issue in a specific region with a specific cloud provider, so it is really hard for me to check what may happen.
Are you using OpenVidu CE or OpenVidu PRO? How much RAM and CPU does the machine have?
We have tried also on another solution we have also in China, that runs on a VM with ISP Chinanet. The white screen there is around two minutes.
We also checked the link with the custom layout, and there the streaming is working as expected, itâs only in the final file that we see the white screen.
We are using Openvidu CE. The machine has 15 GB of RAM and 8 CPU
I donât think this has something to do with the problem. Probably is a network problem (DNS firewalls/filtering in China ISPs or something like that). The machine looks enough in terms of resources).
Then, make sure that this URL loads properly from the server in China. If thatâs the case, you donât need the previous environment variables I have said.
I think the problem is that the webpage donât load properly in China server. If the URL of your custom layout is available from the China server, then try to use localhost to access it.
Obviously, if the page can not be accessed through localhost, and it is not deployed next to openvidu, you will receive that 404
Then, forget about localhost⌠And try to run with OPENVIDU_RECORDING_DEBUG=true. This will print next to the recording some logs about the recording container, which may expose some problem if something is happening.
I am suspecting that the page is taking too much time to load when loaded from the recording container running in China Server. This is why it takes that much time to load.
After checking the logs of recording in the file chrome_debug.logs we found some differences between the recordings without the white screen, the recordings with with screen and the recordings on a server outside China.
I donât know if maybe one of those fetches is causing some kind of timeout. I donât understand those random URLs.
Is your custom layout using those google fonts? Maybe google services are making those requests to timeout because of the China IP (Sad, but it could be a possibility). Some big services use these tricks of long timeout to avoid DDoS attacks. Maybe I am being too paranoid on the thinking, but it is a possibility.
The custom url is a link that is working as expectedly from China.
We are doing some tests and analysis to be sure, but what Iâve noticed so fare that in the recording with white screen the chrome service try trice to fetch this api https://clients2.google.com/service/update2/crx and all the requests fails. In the videos without white screen the chrome service after the second failed request is able to fetch correctly this api, and the issue is not presented
From what I can read in the article, the load of resources outside of China fails inconsistently depending on how firewalls behave. It varies depending on the China region, and it may sometimes work and sometimes not.
What I would do is to locate all needed files from your custom layout in China, so when the page is loaded there, the resources load from a server in the country. In this way, when the web is loaded from China, the files of your custom layout web will not need to pass countryâs firewalls.
The https://clients2.google.com/service/update2/crx comes from the browser itself, some people runs composed recordings without internet connection, so I donât think this is the problem. But I am just speculating.
