CRON - Audio Scripts - Improvements

[aouyar]

Hi Matt,

I have been trying to do some minor improvements to the CRON scripts for audio archival for a Call Center implementation that I have been working on.

In a prior call recording project we had come to the conclusion that it is better to avoid thousands of recording files in a single folder. I am modifying the STEP-1 scripts to improve scalability and to facilitate administration tasks like backups and archival of expired recordings by creating a folder for each day. I am also trying to improve the robustness of the scripts by improving error checking.

Would you be interesting in revising the scripts to see if you will be interested in integrating the changes?

[mflorell]

What version of the scripts are you working off of?

[aouyar]

I have one small client that is using SVN version at production. I am doing all changes on SVN Trunk.

[mflorell]

Very good, please post your changes to the Issue Tracker and link the posting to this topic.

[aouyar]

I have initially modified only the STEP-1 Script and it is at production use now. I do not use STEP-2 and STEP-3 scripts because I record direct to .WAV (GSM encapsulated in WAV format) to tmpfs on /var/spool/monitor and the recordings are moved to /var/spool/recordings/YYYY/MM/dd on completion.

I will be posting the script to the issue tracker after adding some more error checking.

Ali

[okli]

Would this be of any interest too?
http://www.eflo.net/VICIDIALforum/viewtopic.php?t=6552

I've been using it since it was posted without any issues, but always a good idea if someone experienced takes a look on it.

[mflorell]

Yes, I do have that one on my list, but I've been too swamped with paid work to take the time to test it properly and put it into SVN.

[aouyar]

I would rather prefer to use rsync instead of using FTP and scripting tricks to check if the file was transferred correctly. Rsync would be much more reliable than using FTP.

[mflorell]

I would agree with you if we were always transferring to Linux servers, but a sizable chunk of our clients just have simple Windows FTP servers set up to archive recording onto, so FTP is the easiest and most universal way of handling all possible types of archive servers.

[Baylink]

I will concur with the original observation that avoiding directories with too many entries is an excellent plan on *nix systems.

What constitutes "too many" is variable, but generally has to do with the filesystem's implementation of directory storage: if you get the directory contents into extended blocks, things will become unpleasant.

In general, if

Code: Select all

ls

takes more than a second or 3 to start returning results, your directory is too full, and you should hash it somehow.