<div dir="auto">Include in your script to only look at files that are x minutes old. For instance if a file has not been touched in over an hour chances are the call is over.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 8, 2018 11:35 AM, "Carlos Chavez" <<a href="mailto:cursor@telecomab.mx">cursor@telecomab.mx</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/8/18 9:38 AM, Bertrand LUPART - Linkeo.com wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Carlos,<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    We have a server that records all calls so we set Mixmonitor with the b option to only record calls that are actually bridged. I notice that we have lost of 44 byte files in /var/spool/asterisk/monitor which correspond to calls that were not answered.  If a call is not answered I assume it was never bridged so why would Asterisk create a file?<br>
</blockquote>
Which version of asterisk are you running? Looks like this has been fixed some years ago :<br>
<a href="https://reviewboard.asterisk.org/r/2068/diff/" rel="noreferrer" target="_blank">https://reviewboard.asterisk.o<wbr>rg/r/2068/diff/</a><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a way to avoid getting those empty files?  It makes finding recordings vey slow when there are hundreds of non relevant files in the monitor directory.<br>
</blockquote>
You could run a cron job that would periodically delete those 44 bytes files<br>
<br>
<br>
Dispatching audio files in subdirectories may help performance-wise, for example :<br>
<br>
  same => n,MixMonitor(/absolute/path/${<wbr>STRFTIME(${EPOCH},,%Y)}/${STRF<wbr>TIME(${EPOCH},,%m)}/${STRFTIME<wbr>(${EPOCH},,%d)}/${STRFTIME(${<wbr>EPOCH},,%Y-%m-%d)}-${CALLERID(<wbr>num)}-${EXTEN}-${UNIQUEID}.<wbr>gsm)<br>
<br>
<br>
OTH<br>
<br>
</blockquote>
    We are running 13.8.4 at the moment which was the latest when deployed.  I guess the patch never made it to the trunk.  The problem with running a script to cleanup is that you may drag files that are open at the moment but still at 44 bytes because they are still waiting to be bridged.  I may start using subdirectories as you mention but that means I will still have lots of empty files to deal with.<br>
<br>
    Thanks.<br>
<br>
-- <br>
Telecomunicaciones Abiertas de México S.A. de C.V.<br>
Carlos Chávez<br>
<a href="tel:%2B52%20%2855%298116-9161" value="+525581169161" target="_blank">+52 (55)8116-9161</a><br>
<br>
<br>
-- <br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Check out the new Asterisk community forum at: <a href="https://community.asterisk.org/" rel="noreferrer" target="_blank">https://community.asterisk.org<wbr>/</a><br>
<br>
New to Asterisk? Start here:<br>
     <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wik<wbr>i/display/AST/Getting+Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailma<wbr>n/listinfo/asterisk-users</a><br>
</blockquote></div></div>