Good day.
Unfortunately, you cannot fix this file. The file contains a recording data without header, so the header cannot be formed manually.
Seems like there was no free disk space to save mp4 file. But the latest WCS builds can control the disk space and stop recording correctly in this case. By default, there should be at least 1 Gb:
If you recording files may be more than 1 Gb, please increase the threshold value, for example
Unfortunately, you cannot fix this file. The file contains a recording data without header, so the header cannot be formed manually.
Seems like there was no free disk space to save mp4 file. But the latest WCS builds can control the disk space and stop recording correctly in this case. By default, there should be at least 1 Gb:
Code:
file_recorder_min_space=1g
Code:
file_recorder_min_space=10g
djuka
Member
Hi Max, it was not a lack of disk space. On that disk, there is 2TB of free space.
I had 20 multi-stream recordings in 2 hours; only 3 of them are not finished properly and have only *.mp4.tmp files. The other 17 finished mixing correctly.
This situation happens each day, most of the multi-stream recordings went OK, but a few of them finished as corrupted files *.mp4.tmp
I had 20 multi-stream recordings in 2 hours; only 3 of them are not finished properly and have only *.mp4.tmp files. The other 17 finished mixing correctly.
This situation happens each day, most of the multi-stream recordings went OK, but a few of them finished as corrupted files *.mp4.tmp
Last edited:
We raised the ticket WCS-4053. Please reproduce the problem, collect a report Getting logs with report.sh script and send using this form.
We checked the report. In the logs provided, there are no any multiple recordings, but single stream recodings only, and all of them seems to be successful. So the problem seems to be not reproduced during the last 3 hours (logs collection time by default).
In the ticket WCS-4053 scope, we plan to optimize recording flow to exclude an excessive file rewriting, and to write MP4 header on the fly. This should allow to play the file even if recording was incorrectly stopped. But this may require a time.
You can do the following for more stable server work:
1. Add more Java heap space. Now, you're using a default Java heap size 1 Gb. It may be not enough because recording data are kept in Java heap memory. We recommend to use 1/2 of server RAM, 6 Gb in your case
2. Seems you are using JDK 8 and CMS garbage collector. We recommend to update JDK to 14 or 15: JDK 14, JDK 15 and enable ZGC: The Z Garbage Collector. This may reduce a garbage collection pauses in Java machine work cycle, and increase a performance.
In the ticket WCS-4053 scope, we plan to optimize recording flow to exclude an excessive file rewriting, and to write MP4 header on the fly. This should allow to play the file even if recording was incorrectly stopped. But this may require a time.
You can do the following for more stable server work:
1. Add more Java heap space. Now, you're using a default Java heap size 1 Gb. It may be not enough because recording data are kept in Java heap memory. We recommend to use 1/2 of server RAM, 6 Gb in your case
Code:
-Xms6g
-Xmx6gdjuka
Member
Hi, I did what you suggested, but the same issue happened today. Two multi-stream recordings failed and 5 went OK. I caught a report within a 3-hour frame but can not send you using the support form since it is not working.
Add: After the recommended change it works worse. Today I have more corrupted videos.
Add: After the recommended change it works worse. Today I have more corrupted videos.
Last edited:
Hello
If you have any issues with the private form, please send directly to support@flashphoner.com and add forum thread link into your message
If you have any issues with the private form, please send directly to support@flashphoner.com and add forum thread link into your message
djuka
Member
Hi Max,
I want to inform you that I found the issue. The recording file was not corrupted but MultiRecorder was not finished since the session was never terminated. I used '/multipleRecorder/find_all' rest API endpoint and I found all 'broken' video files are not closed by the recorder. When I manually terminated all recorders, all files went to the mixer and finished as OK.
I want to inform you that I found the issue. The recording file was not corrupted but MultiRecorder was not finished since the session was never terminated. I used '/multipleRecorder/find_all' rest API endpoint and I found all 'broken' video files are not closed by the recorder. When I manually terminated all recorders, all files went to the mixer and finished as OK.
We tested report sending via
Report, it works now.This is an expected behavior: multiple recorder must be started and stopped by REST API because it never knows when a stream will be added or removed from it. You should review your backend flow to stop multirecorder when room is closed.
We will still work on the ticket WCS-4053 to prevent an excessive file rewriting when recorder is stopped.