When we start to record a video using licode, we get recording id immediately. However, sometimes video recording does not start and no .mkv file gets created. This does not happen all the time.
How can this failure be avoided and ensured that mkv file gets created for sure? If not avoided, how can we catch that mkv file creation has failed even when recording id has been issued?
Any suggestions will be highly appreciated.
Create a “monitor”. That should not be too difficult to achieve without making changes to the actual Licode code.
I have not done this with Licode, but I have done it in other cases.
- Create a separate process or a timed check in Node. (Each Node is a single process, but you may emulate threads)
- Inform that process (or check) that you have started recording.
- Check if an actual file has been created within a certain time.
- Check if the file grows when you are recording.
- If the file has not been created, then you have got a failure.
- If the file is not growing, then you have just created it, but no recording.
- If no file or no recording, then try to start recording again. You may inform the users of the issue or do whatever you want.
This should be fairly easy to implement and it will not require much resources.
This is not an actual fix, but a workaround. You can use Node for doing this. Or you may use some other language.
Thank you @jjahifi for your suggestion! Well, we are already doing this workaround, but it does not seem right. This is a very basic exception and I imagine there should be something in Licode to handle or at least provide a callback.
I assume that it would not be very difficult to modify Licode in order to handle the issue. But personally I am very happy to use an easy to do workaround instead of digging deeper in the actual Licode code.
I agree that the workaround is an ugly hack. But sometimes a little bit of ugliness is ok for a simple to implement solution.
It does look like Erizo is not reporting properly the failures that can take place when starting a new recording, this includes insufficient disk size, errors in configuration, etc.
We will work to fix it, in the mean time you will have to relay in the workaround and you can also check the erizoJS logs, these problems are properly logged with
Thank you @pedro! Well, these errors do not seem to be due to disk size.
Also, we see this problem only about 15% times and not always, so not so
what is the issue. I will look into erizoJS logs in detail. Thanks!