asterisk users - Jan 2018 - Mixmonitor with b option

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

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.

On Jan 8, 2018 11:35 AM, "Carlos Chavez" <cursor at
telecomab.mx> wrote:
> 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)}/${STRF
>> TIME(${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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>      https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180108/bd4e7808/attachment.html>

On 8 Jan 2018, at 18:44, Dovid Bender <dovid at telecurve.com>
wrote:
> On Jan 8, 2018 11:35 AM, "Carlos Chavez" <cursor at
telecomab.mx> wrote:
>>     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.
> 
> 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.
Alternatively, you could run a command by MixMonitor() which 'Will be
executed when the recording is over.' This command would check if
MIXMONITOR_FILENAME is 44 bytes or less and act accordingly.

https://wiki.asterisk.org/wiki/display/AST/Application_MixMonitor

-- 
Bertrand LUPART

Linkeo.com - 23, rue des grands Augustins - 75006 Paris

>>>    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/
[?]
>    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.
Good guess, i guess.

https://issues.asterisk.org/jira/browse/ASTERISK-20156

-- 
Bertrand LUPART

Linkeo.com - 23, rue des grands Augustins - 75006 Paris