Summary:	ASTERISK-16945: AMI command stopMonitor followed by Monitor do not create a new file, just change the name of the original file and append to it
Reporter:	Chris A. Icide (cicide)	Labels:
Date Opened:	2010-11-11 16:01:15.000-0600	Date Closed:	2012-02-27 12:17:18.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The AMI stopMonitor command when used after Monitoring has begun (using AMI Monitor command in my testing scenarios) correctly stops Monitoring of a channel.   With the goal of creating a new recording from a later start point, while saving the original recording under it's original name, I issue a new AMI Monitor command with a different file name. The expected functionality would be that I would end up with two sets of files, one set from the first recording with the filename used by the first monitor command, and a second set of files with the filename from the second monitor command. However, currently what occurs is that a single file with both periods of recorded audio is saved with the final filename.
Comments:	By: John Todd (jtodd) 2010-11-11 16:12:34.000-0600 Hmm... that pretty much defeats the whole functionality of the AMI StopMonitor command entirely.  Bad. By: Richard Mudgett (rmudgett) 2012-02-14 15:59:07.611-0600 We are working through the backlog of issues and this issue came to the top of the list.  I am not able to reproduce this on v1.8 and the res_monitor code did not have any changes that could account for your problem description. I have tried: {noformat} Action: Monitor Channel: SIP/100-00000001 File: capture_file1 Action: StopMonitor Channel: SIP/100-00000001 Action: Monitor Channel: SIP/100-00000001 File: capture_file2 Action: StopMonitor Channel: SIP/100-00000001 {noformat} This gave me the expected capture_file1 and capture_file2 files with the expected content. {noformat} Action: Monitor Channel: SIP/100-00000001 Action: StopMonitor Channel: SIP/100-00000001 Action: Monitor Channel: SIP/100-00000001 Action: StopMonitor Channel: SIP/100-00000001 {noformat} This gave me the expected SIP-100-00000001 files.  The contents of these files only contained the second part of the monitor capture because the new capture is supposed to overwrite the old. Can you give me a trace of the AMI actions you used to create this problem? By: Richard Mudgett (rmudgett) 2012-02-27 12:17:18.864-0600 Closing due to no response and could not reproduce issue.