asterisk users - Jan 2018 - Mixmonitor with b option

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?  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.


-- 
Telecomunicaciones Abiertas de M?xico S.A. de C.V.
Carlos Ch?vez
+52 (55)8116-9161

Hello Carlos,

>    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?
Which version of asterisk are you running? Looks like this has been fixed some
years ago :
https://reviewboard.asterisk.org/r/2068/diff/

> 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.
You could run a cron job that would periodically delete those 44 bytes files


Dispatching audio files in subdirectories may help performance-wise, for example
:

 same =>
n,MixMonitor(/absolute/path/${STRFTIME(${EPOCH},,%Y)}/${STRFTIME(${EPOCH},,%m)}/${STRFTIME(${EPOCH},,%d)}/${STRFTIME(${EPOCH},,%Y-%m-%d)}-${CALLERID(num)}-${EXTEN}-${UNIQUEID}.gsm)


OTH

-- 
Bertrand LUPART

On 1/8/18 9:38 AM, Bertrand LUPART - Linkeo.com wrote:
> Hello Carlos,
>
>
>>     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?
> Which version of asterisk are you running? Looks like this has been fixed
some years ago :
> https://reviewboard.asterisk.org/r/2068/diff/
>
>
>> 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.
> You could run a cron job that would periodically delete those 44 bytes
files
>
>
> Dispatching audio files in subdirectories may help performance-wise, for
example :
>
>   same =>
n,MixMonitor(/absolute/path/${STRFTIME(${EPOCH},,%Y)}/${STRFTIME(${EPOCH},,%m)}/${STRFTIME(${EPOCH},,%d)}/${STRFTIME(${EPOCH},,%Y-%m-%d)}-${CALLERID(num)}-${EXTEN}-${UNIQUEID}.gsm)
>
>
> OTH
>
     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.

     Thanks.

-- 
Telecomunicaciones Abiertas de M?xico S.A. de C.V.
Carlos Ch?vez
+52 (55)8116-9161