[asterisk-dev] temporary file names for monitor files
John Lange
john at johnlange.ca
Fri May 30 14:02:07 CDT 2008
Well ok then! That is exactly the way it should be done. No need for a
new patch.
I'm glad I asked because I've never heard of that option before.
Thanks
--
John Lange
www.johnlange.ca
On Fri, 2008-05-30 at 20:55 +0200, Johan Wilfer wrote:
> You also have the -t flag you can add to asterisk at startup to make
> asterisk record to another directory and then move the file.
> This is not what you ask for but a related function. I've missed this
> one completely, stumbled on it yesterday.
>
> "Usage: asterisk [OPTIONS]
> -t Record soundfiles in /var/tmp and move them where they
> belong after they are done"
>
> /Johan
>
> Dmitry Andrianov wrote:
> > As I understand Asterisk writes data to a file as soon as it receives it on the channel. And this means the file will start getting data almost immediately after creation, not when the call is complete.
> >
> > Writing to a .tmp file which is later renamed to a file without .tmp suffix is classic way of solving the problem. A LOT of applications do that. Checking modification time is more like a workaround to me.
> >
> >
> > -----Original Message-----
> > From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Sherwood McGowan
> > Sent: Friday, May 30, 2008 2:49 PM
> > To: Asterisk Developers Mailing List
> > Subject: Re: [asterisk-dev] temporary file names for monitor files
> >
> > Tzafrir Cohen wrote:
> >
> >> On Thu, May 29, 2008 at 05:24:48PM -0500, John Lange wrote:
> >>
> >>
> >>> Does it make sense to write a patch for Asterisk so that while a
> >>> recording is in progress, the file has a '.part' extension on the file
> >>> name to differentiate it from files in which recording has finished.
> >>>
> >>> The idea here is that if you want to move your recordings off to another
> >>> place once you have finished you can write a simple "cron" to do it
> >>> without having to worry if the recording has completed or not.
> >>>
> >>> I realize this could be done through dialplan logic but seems to me that
> >>> this is a more logical way to tackle this problem.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >> Renaming at the end of a call?
> >>
> >> All to similar to the task of the mixmonitor script. Couldn't this be
> >> implemented that way?
> >>
> >>
> >>
> > As I read it (pardon me if I'm misunderstanding your question), he wants
> > the .tmp or .part to be removed from the filename after the file is
> > finished being written to, thereby allowing a simpler method of knowing
> > when the file is completed being written to.
> >
> > I haven't tested in depth, but I believe that the file is created but
> > does not have data in it until after the call is completed, but still we
> > don't want to modify/copy/move the file until after it's finished being
> > written to. Since you're not sure when the file is done being modified
> > by Asterisk, the only thing you can do is check for a modification time
> > that is more than x seconds/minutes in the past and then do what you
> > wish to do to the file.
> >
> > However, your reminder of the mixmonitor script is good, I think I'll
> > take a peek into the code and try to get an idea of two.
> >
> > Sherwood McGowan
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
More information about the asterisk-dev
mailing list