"Too many files in. . ."

I am getting this SAME EXACT issue. We are about to try just rotating out the files but there is probably some setting in a configuration file. Please if you know please please please help us! Thank you!!!!

Will Trixbox 2.0 fix this?

Oh ya, what file system are you using?
I am using Ext3. One of our developers told me something about the Ext3 filesystem only allowing X many files in a directory. He said something about that being the reason for the "To many files" error. That is also the reason I tried to get each extension, and date, into its own directory.

Anyone?

anyway, some more info: I had to clear the monitor directory again, I had to delete everything prior to September.

Here's the thing though: it is still recording perfectly fine, so I don't think it's a filesystem error. I think it's a FreePBX error. I am not familiar enough with the project to know where to look for the code, but is it possible there is a limitation in any arrays used to enumerate the files prompting this error? It's frustrating because when we have to revisit calls to verify orders to make sure we get things right we're unable to review the calls until I get a chance to go in and purge older files. Since it's still happily creating the voice recordings it's obviously not a filesystem issue.

Running into this again. I edited php.ini:

memory_limit = 128M

And restarted httpd. Same issue, still encountering the error.

I find it hard to believe that no one else is encountering this issue. We're hitting this after a couple of months of calls with only three lines seeing regular use.

OK, after about two minutes of digging we found it

edit: bootstrap.php

In: /var/www/html/recordings/includes

It is hard-coded to not handle more than 3000 files.

Line 112,

        if ($fileCount>3000) {
          $_SESSION['ari_error']
            .= _("To many files in $msg_path Not all files processed") . "<br>";
          return;
        }

We're changing this to make it a setting. The question is: why is this limitation here in the first place?

Do you do call monitoring? These are all valid WAV files. If you have nothing in /var/spool/asterisk/monitor then you do not have call monitoring enabled. We have it enabled because we have to test it for support for our clients, and for "quality assurance purposes" (e.g., when we bring in reps we need to make sure they're not trying to screw or piss off the customer, etc.), typical call center stuff. Our clients actively use it, we have it enabled for testing but will be actively using it starting in the coming months.

So the question is not why are there so many files in there (that's kind of a 'duh' question, to be quite honest, and I truly mean no offense there) but why is that limit encoded into the php in the first place? It is obviously not a filesystem limitation because ext3 can handle many tens of thousands of files in a directory, and it's obviously not a kernel limitation in this case (the ONE article I've found on this issue claimed it was a kernel limitation, requiring a reconfiguration/recompile). Did someone, when implementing ARI, think "gee, 640K, er, 3000 files ought to be enough for anyone?" ;)

Has anyone found a solution to this as yet? I just ran into it for the first time with one of our call centers running call logging (aka monitoring). Did raising the artificial 3000 limit relieve the problem?

- J

bumpity, anyone? - J

The ext3 filesystem has a limit on how many file entries are in a directory. I think the PHP limit is there to warn you if the number of recorded conversations is already approaching that limit.

Try using cron to move the recording files to a different directory each day. That should solve the directory/file number limitation.

I raised my limit from 3000 to 30000 and all is well.

I have found that if you rise the limit to a large number a timeout error is displayed.

Yondaime: Can you adjust the script to move old wave files into backup directory like every new month create new backup directory.

Also where can I register this file to auto run every X days?

Just thought I'd let people know, the monitor directory I mentioned in my previous post is a symlink. I removed it and increased my limit from 3000 to 300,000,000 and everything is working flawlessly (as far as I can see).