Asterisk Recording / Monitoring - Recordings exist but no Play link in ARI

Hi,

Customer just called me, they said they lost recordings. Upon checking their system, all recordings are working and exist under /var/spool/asterisk/monitor .

From the 13th March (last week), the ARI portal doesn’t show a Play link beside any call for any users. The calls are definitely recorded however.

There are about 130,000 calls in the /var/spool/asterisk/monitor . I already performed the change to increase the MAX files issue a while ago.

Is there anyway I can find out whats wrong, and why the play link is not showing anymore?

I’ve googled to no avail!

Thanks,

Stephen.

EDIT

Well, I fixed the error by changing the following in main.conf.php

$CALLMONITOR_ONLY_EXACT_MATCHING = 1;

To

$CALLMONITOR_ONLY_EXACT_MATCHING = 0;

I then fixed the MAXFiles issue by changing the following line to allow 300000 files in bootstrap.php:

$fileCount++;
if ($fileCount>300000) {
$_SESSION[‘ari_error’]
.= _(“To many files in $msg_path Not all files processed”) . “
”;
return;
}

Not sure why things went weird from the 13th March, but that’s friday the 13th for you. Anyway, got it fixed, so thats all that matters.

It probably happened as you exceeded the previous number of allowed files.

Please be aware that having it pull up that many files will directly impact performance. It needs to have memory to load all those names (64 bytes to store a file name * 130000 names is over 8 meg of ram just for the file names), scan all the file names and match them to database records, generate the html, have the client download the html, etc. Those are just a few of the reasons that the limits were put in place to begin with.

Depending on the partition’s underlying file system you will be hitting performance limits. The standard default setting of ext2 and ext3 are not designed to regularly deal with hundreds of thousands of files in a single directory node. Can it do it sure, can it do it well, heck no.

You might want to consider taking the time and pruning the number of files stored in a single given directory into a reasonable number. I’d hate to see how long the system will check the drive if it is rebooted and/or a disk check is forced for a reason out of your control.

Nothing like a unplanned power hit that in the end forces you to reboot the system, watch because it will only be when you are in a hurry to get it up and operational, then you’ll suddenly be stuck for hours waiting for it to check that the disk is actually clean before it will actually boot all the way. The biggest amount of time consumed in a disk check is checking all the node points and verifying that everything is ok and nothing is cross linked. (We found that out the hard way on a disk with many nested directories containing 1.3 billion 200 byte or less files).