Hi everyone!
I faced some strange behavior while testing the COMPOSED_QUICK_START recorder.
I’m using OpenVidu Pro 2.25.0 deployed via AWS CloudFormation.
Conditions:
I started video recording and reloaded the recording webpage without properly stopping the COMPOSED_QUICK_START recorder. In this case, all following recorded videos have a black screen with the following text message:
“The profile appears to be in use by another Google Chrome process (39) on another computer (ip-172-31-5-169). Chrome has locked the profile so that it doesn’t get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Chrome.”
How can I fix that? I should predict situations when some users accidentally close or reload the recording webpage.
Also I didn’t face such things on OpenVidu CE 2.25.0 deployed on premises.
Thanks!
I uploaded OpenVidu server logs to Google Drive: Link
What do you mean with “reloaded the recording webpage” ? How do you reload the recording web page?
I mean refresh the webpage using Command+R on Safari or F5 on Chrome.
But you mean your web application’s page? I did not understand the concept of reloading the recording page. Let me see if we are on the same page:
- You have a web app that uses OpenVidu.
- You record your OpenVidu sessions using COMPOSED_QUICK_START recording mode.
If the user reloads your application web page in its device, the following resulting recording files are all like the picture you attached?
Yes, that’s right. Sorry for my English.
That’s so weird. I cannot see the relation between a final user refreshing the OpenVidu web app and the recording module being affected by that. It is its own separate thing, with no interaction other than receiving and recording the media of the users. Do you have a reliable way of replicating the problem? You say that with an official deployment of OpenVidu 2.25.0 in AWS (like this AWS - OpenVidu Docs) should be possible to get this behavior, right?
That’s really weird… but the problem was fixed when I deleted the previous OpenVidu CloudFormation stack and deployed a new one with the same parameters.
Thanks for your time.
If you get the same behavior again, please come back to this forum topic and we will discuss the problem.
1 Like
I found a way to reproduce this behavior.
Actually, the default OpenVidu PRO installation on AWS works fine, but this strange behavior reproduces if I add an image overlay in composed_quick_start.sh (openvidu/openvidu-recording:2.25.0) by adding:
-i /watermark.png -filter_complex "[2:v][1:v] scale2ref=w=oh*mdar:h=ih*0.05 [watermark][video];[video][watermark] overlay=10:10 [stream]" -map "[stream]" -map 0:a
into this code:
<./stop ffmpeg -y -f alsa -i pulse -f x11grab -draw_mouse 0 -framerate $FRAMERATE -video_size $RESOLUTION -i :$DISPLAY_NUM ..........
I know that is not a problem with the default OpenVidu Pro Server, but maybe you can give me some advice. I used this approach with OpenVidu CE and it works fine, but for some reason, it not works with the Pro version.
(I’m using this approach for the watermark instead of the gdkpixbufoverlay filter because this filter can change watermark width and height on video if video stream resolution changes on the fly)
You have to be extremely careful when modifying the official ffmpeg command inside the recording container, or things may start going the wrong way. The recording container is exactly the same for the CE and PRO/ENTERPRISE versions, as long as the version number of the OpenVidu deployment is the same. OpenVidu CE 2.25.0 and OpenVidu PRO 2.25.0 use the exact same recording container.
Also, I cannot see any kind of relation between the Chrome warning pop-up that you posted in your first message, and the modification of the internal ffmpeg command inside the recording container.
I think the problem must be related to a change in the host IP address and the Google Chrome process inside the recording container somehow knowing about that change. A COMPOSED_QUICK_START recording container is tied to the lifespan of its OpenVidu Session. I don’t see how your Media Node IP address could change during the lifespan of an OpenVidu Session (and the Chrome profile inside the recording container being automatically modified), that is very strange.
So, if you have already commited to modify and mantain your own version of the recording container, just delete the Chrome profile data just before the Chrome process launch command. I’ve found online that this sould be something like:
rm -rf ~/.config/chromium/Singleton*
or
rm -rf ~/.config/google-chrome/Singleton*
Those files are only a few bytes in size, so the deletion process should be quick.
Give this a try and let us know.
1 Like
