Recordings and AST_CRON_audio_1_move scripts
Posted: Fri Sep 26, 2014 9:12 amHi,
Using Vicibox 6.0.1, SVN 2173, clustered setup, 1 DB, 1 Web, 3 Telephony servers- Asterisk 1.8.29.0-vici
SoftRAID1, ext4 with 4KiB block
I was after some broken recordings and realised that when recording is on progress, file size updates every ~20 seconds, flushing 32768 bytes on the disk at a time, whereas AST_CRON_audio_1_move* scripts check for file size update after only 5 seconds pause. Therefore, if the cron job kicks in meanwhile, between two disk flushes, the file is moved to DONE directory, even though recording is still in progress, kinda hit and miss.
Monitoring with
Results were similar with recordings set in RAM and on DISK.
Same result on one of the other telephony servers.
The obvious fix would be to increase pause length in AST_CRON_audio_1_move* to say 25 seconds and amend cron job interval so jobs don't bump into each other, but before doing that, I'd rather ask what your thoughts are about this and I am missing something obvious.
Added: It appears that if using WAV recordings, with their much larger size, the issue is not present as file size changes way more often.
Should I just stick to WAV and compress the recordings afterwards, something I'd like to avoid?
Using Vicibox 6.0.1, SVN 2173, clustered setup, 1 DB, 1 Web, 3 Telephony servers- Asterisk 1.8.29.0-vici
SoftRAID1, ext4 with 4KiB block
I was after some broken recordings and realised that when recording is on progress, file size updates every ~20 seconds, flushing 32768 bytes on the disk at a time, whereas AST_CRON_audio_1_move* scripts check for file size update after only 5 seconds pause. Therefore, if the cron job kicks in meanwhile, between two disk flushes, the file is moved to DONE directory, even though recording is still in progress, kinda hit and miss.
Monitoring with
- Code: Select all
watch -n 1 'date && ls -l /var/spool/asterisk/monitor/'
Results were similar with recordings set in RAM and on DISK.
Same result on one of the other telephony servers.
The obvious fix would be to increase pause length in AST_CRON_audio_1_move* to say 25 seconds and amend cron job interval so jobs don't bump into each other, but before doing that, I'd rather ask what your thoughts are about this and I am missing something obvious.
Added: It appears that if using WAV recordings, with their much larger size, the issue is not present as file size changes way more often.
Should I just stick to WAV and compress the recordings afterwards, something I'd like to avoid?