We have an application that allows session recording on an as required, INDIVIDUAL basis.
We have noticed that some times one participant is missing from the recording but present when the record API call was made. This only was reported to me recently so I do not know if it relates to a recent 2.15 upgrade or not.
The participant missing from the recording was interactive with the other participants and had no network or other issues. This was a 4 participant session, one was missing from the recording.
I know there was a related issue, but for recording ALWAYS before.
A bug?
John
It can be a bug.
Can you share OpenVidu server logs? Do you have some way to reproduce it?
Micael,
Actually no, it appears that we hit a zip file limit as the total webm sizes exceed 9Gb in total. Is there a way to disable the zip routine that runs on the INDIVIDUAL recordings?
We ended up with a zip files as well as left over files that do not appear to have made it into the zip. Would this be logged somewhere?
We are improving recording features right now so in the near future you will be able to disable .zip for individual recordings.
I don’t understand your last message. What is exactly what you want?
Micael,
We need a way to disable the zip process now - the zip process errors on files over 4Gb in size and our recordings exceed this. How can we do this?
Right now it is not possible.
If you are using OpenVidu CE, you can change the code yourself. But if you are using OpenVidu PRO, you will have to wait until next version. We will try to publish a nightly version when we implement the feature so you can use it as soon as possible
Regards
We’ll be working on this now.
Hello,
I’ve been performing some tests today… And I wasn’t able to reproduce any kind of problem. I just generated an INDIVIDUAL recording with some small files and a big 7.8GB file. The compression process run successfully (took 6 minutes to complete). The file was generated OK (didn’t compressed it much, though):
How can I reproduce the problem? Thank you for your answer.
The first file we noticed an issue with was over 9.2Gb in size. What we saw was the session folder and it contained a zip file and some left over webm files.
This appears to be what occurs when the zip file becomes too large, the files are just left there that didn’t yet get zipped.
I haven’t tried to duplicate this issue specifically and I wasn’t sure what zip version or what the Java zip process you use is doing.
John
So… This has nothing to do with files over 4GB?
I was afraid after reading this message that the internal Java Zip SDK was using standard ZIP (that doesn’t support files over 4GB) instead of supporting ZIP64 (that has no real limit), but this proves not to be a problem.
I guess I’ll try again with a >9GB file and see what happens. Will post here the results.
The 9.2Gb is the total of the uncompressed files - 4 webm files. I do not know what the Java Zip SDK limit it. I asked a Java dev to look at this and he was the one who brought up the file limit issue and said he has seen stability issues with large files in this type of situation. I do not see anything regarding this in logs and the partial zip plus the excess webm files appeared to be a sign.
