Recordings are incomplete

[Op3r]

I am having problems with the automatic recordings. It seems that the auto dial recordings are incomplete but on manual dial they are complete

any ideas?

[mflorell]

please explain what you mena by "complete"

What is the loadavg when this happens?

What kind of hard drives are you using?

Do any errors show up in the Asterisk CLI for the time onf the incompleteness?

[Op3r]

the loadavg is 2.63, 0.79, 0.89

I mean the recorded calls arent complete meaning it stops recording prematurely. Im using 2 SATA drives on each of my asterisk.

Im quite stump but anyway Ill try to use mixmonitor if it improves the situation.

[mflorell]

Do they stop at a set time after starting or is their stop time random?

How many recordings do you record at once?

[Op3r]

Im also experiencing this kind of problem again but on a different settings.

When I am using a sip trunk the autodial recordings are complete. But when I tried utilizing the TDM card (te411p) the recordings stop at 5 minutes.

I am quite bummed by this. Any idea?

the server is a dual xeon with 4 gb of memory and 3x76gb SCSI hard drive. running 2.0.3 with a te411p installed.

[mflorell]

Are they all exactly the same length of time?

I have not seen this happen before.

If you still have a TE411P you should consider trading it in for a TE412P from digium. They should still be swapping these out for free if you complain.

[chrisbIT]

Sorry to drag up an old topic but I seem to have the same problem.

We are only in the early testing stages and currently only running one campaign with a couple of callers. One of the guys got his first sale a little while ago so i listened to the call recording which terminated after 4m57s. The file size is 480k. Looking in the ORIG folder the "in" file is 609k and the "out" file 0k. listening to the 609k file it does indeed go on for a further minute and the sale is made. Is this anything to do with the every 5 min cron job?

Thanks.

Chris

[mflorell]

It shouldn't be because of the cron script, that will detect if the file is being written to and will not transfer it it is. You could always edit that script to add a few more seconds to the "sleep()" command to see if that helps.

I have not experienced this problem on any of my systems that are using the 5-minute cron though so I'm not exactly sure what would be causing it.

I would recommend trying the VDonly_date version of the script that is in SVN, because it does not do a mix before transferring the audio file. Not sure if that would help, but it's worth a try.

[Op3r]

I reinstalled soxmix and the issue went away.

[mflorell]

That's very weird, do you know what version of sox you were using before?

[Op3r]

I cant remember which version but i assume it is the same. Cos I reinstalled it 2 days after I am having that kind of problem. I guess I thought soxmix was installed improperly.

that kind of problem is very frequent on centos installs though thats for sure. I havent had that kind of problems when using debian or gentoo. At first it spooked me out but then again reinstalling soxmix was the only thing that can make it work.

[chrisbIT]

just upped the sleep command from 1 to 5 seconds. Will see how it goes.

Thanks.

Chris

[chrisbIT]

reinstalling sox did not help, but what did was using recording extension 8309 (wav) as opposed to 8310 (gsm), it seems that gsm files do not get larger enough to be noticed by the mixing script. as soon as the script is called (by cron or manually), gsm's get mixed straight away. Recording as wav initially seems to solve this problem (these can then be changed to gsm or mp3 by choosing the correct mix script).

Thanks.

Chris

[mflorell]

For machine load issues I do not recommend recording directly to GSM, so maybe that is the reason I haven't seen this problem since none of my production systems record to GSM