You’re welcome. I found the answer, see my previous post (which will probably appear BELOW this one because I forgot to attach it as a reply, and apparently there’s no way to delete a message if you did it wrong).
I spotted that but ran out of time before heading out to work. The $amp_conf is not needed as we don’t have any calls to retrieve amp_conf variables.
I have republished the module with all fixes, please download it again and test.
Thanks for the feedback.
Have you tested the playback of recordings?
The revised one installs fine.
Haven’t tested playback of recordings because I’ve never actually had a reason to create a recording (I assume you mean a recoding of a call, and I don’t even remember the code for that offhand), therefore there are none on the system, and I need to leave in a few minutes. Maybe later tonight I will give that a try.
Thanks for the feedback. As for recording, just set an extension to Record Incoming to Always and dial into it a couple of times. Then set it back to what it was.
Any other takers for testing the playback of recorded calls?
Okay, I tested playback of recordings on a Mac (OS X 10.5.8) using Firefox, Safari, Chrome, and Opera. In Firefox, Safari and Chrome they played fine using the QuickTime plug-in. In Opera they played fine also although some of the controls were not available, for example you couldn’t pause the recording. I think this may be an Opera or a QuickTime issue.
Also tested on Firefox, Chrome and Opera on Ubuntu Linux 10.10. In Firefox it plays fine there also, using the “Totem Browser Plug-In”. In Chrome and Opera, it just says “Missing Plug-in” where the control should be. There’s probably a fix for that, but since I don’t use that system for web browsing I’m not going to worry about it, and I’m inclined to think it’s not a problem with your software because a quick Google search tells me that a LOT of people have problems getting sound to play in Ubuntu, when using browsers other than Firefox (and Google Chrome users apparently even have issues getting sound to play under some versions of Windows, so there’s that).
Just a note for anyone testing this that wants to see the DID field actually populated. For now you can add a context at the bottom of /etc/asterisk/extensions_custom.conf
[custom-from-trunk-did]
exten => _X!,1,Set(CDR(did)=${EXTEN})
exten => _X!,n,Goto(from-trunk,${EXTEN},1)
exten => h,1,Macro(hangupcall,)
Then in any trunk that handles incoming calls, set the context statement to context=custom-from-trunk-did (assuming the statement was originally context=from-trunk).
If the context statement in a trunk points to something other than from-trunk, there are a couple of ways to handle it. If it went to another custom context that you created, just add a line to that custom context that includes the Set(CDR(did)=${EXTEN}) instruction. If you went to some other valid internal context (for example, from-pstn-e164-us, from-pstn-toheader, etc.) just create another corresponding context in extensions_custom conf, for example:
[custom-from-pstn-e164-us-did]
exten => _X!,1,Set(CDR(did)=${EXTEN})
exten => _X!,n,Goto(from-pstn-e164-us,${EXTEN},1)
exten => h,1,Macro(hangupcall,)
And then change the trunk context line to point to the appropriate custom context. But keep in mind that whenever this module becomes part of the official distribution, code to set the DID field in the CDR records will probably be added to from-trunk and similar contexts, making these custom contexts redundant at best.
Ran into an issue testing the CDR Viewer on my PBX in a Flash setup FreePBX 2.9. If I raise the result limit to 10,000 or higher and check the export to CSV it crashes (after about 10 seconds). However if I try to do the 10,000 and only check the cdr search it works.
Well, I can put in a limit on that, 10,000 entries are a lot of entries:-)
I guess that memory is exhausted in php and that is why it crashes. Is there any error in apache error_log?
Update:
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/admin/modules/cdr/crypt.php on line 0, referer: http://192.168.0.205/admin/config.php?type=tool&display=cdr
Could you test this, in functions.inc.php add the following from:
function cdr_export_csv($csvdata) {
global $db;
$fname = "cdr__" . (string) time() . $_SERVER["SERVER_NAME"] . ".csv";to
function cdr_export_csv($csvdata) {
global $db;
set_time_limit(3000);
$fname = "cdr__" . (string) time() . $_SERVER["SERVER_NAME"] . ".csv";Then test it again.
Update 2:
Just tested it with 10,000 records, it took almost a minute, then I could download it.
Thanks for the report.
Thanks It works now without crashing. However took about 2 min on the system I am running. Bad thing is that I need to create a csv of our monthly call logs for reporting. So I went directly to the database and queried the past month August 1st through August 31 I have 62,000 + lines!!! So any suggestions on a better way. I was testing making a cron job to query the DB and then upload it to my FTP but kept getting issues with too many arguments. Its been a long week so maybe I am missing something… Thanks for the help in advance
Unfortunately, it will take some time to process 62,000+ lines.
I wonder how long it took for the old cdr report tool to process that. Hmmm, I need to test it.
The old reports take a long time too. Taking 2+ minutes would not be unreasonable.
BF
I have a CDR DB with 7M+ records. Would you like me to see what happens with that data set?
That was 2+ minutes on the 10,000. The issue is that some months we may have 60,000 lines and others we may have 70,000 or even 80,000 lines. When I query the Database manually and email to my self it creates a ~13Meg file of all 60,000+ lines, in about 1 min and then I have it in my Personal Inbox (Not PBX Mailbox) within another minute or 2.
I am looking into it, it is the foreach loop that is taking time.
If I select 10,000 records, the select for that take about 0,4 seconds, the foreach loop that populates the csv take 43 seconds.
I will try to see if I can optimize the code foreach or do another approach.
@SkykingOH, I have a rather large cdr database to play with:
mysql> select count(*) from cdr;
+----------+
| count(*) |
+----------+
| 879652 |
+----------+OK, I have now tweaked the code a bit, I found where the time was spent in the code.
With 10,000 records, it took about 50 seconds to generate the csv export, with this code it will take about 0,6 seconds to export to csv.
In functions.inc.php replace the function cdr_export_csv with this code:
function cdr_export_csv($csvdata) {
set_time_limit(3000);
$fname = "cdr__" . (string) time() . $_SERVER["SERVER_NAME"] . ".csv";
$csv_header ="calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield\n";
$data = $csv_header;
foreach ($csvdata as $csv => $value)
{
$tmp = '';
foreach ($value as $csv_key => $csv_val)
{
// If the string contains a comma, enclose it in double-quotes.
if (strpos($csv_val, ",") !== FALSE) {
$csv_val = "\"" . $csv_val . "\"";
}
$tmp .= ",$csv_val";
}
$data .= substr($tmp, 1)."\n";
}
cdr_download($data, $fname);
return;
}Please test and report back.
On my system it seems to break it like prior to adding the time limit.
Log show this error
Call to undefined function cdr_ob_clean_all() in /var/www/html/admin/modules/cdr/functions.inc.php on line 160,
Update:
My mistake went a bit too far on the function selection!!
You probably removed the function when pasting in the fix. That function code was after after the replacement code.
Works great got 62,000 + results in <30. I will keep testing. Any Possibility of adding a find all results to this?
Something is causing a column shift with Lastapp and Lastdata Duration, Billable sec and proceeding columns are off. Looking into it.
Update:
lastapp column is shifting on us. Also clid is flowing over into src on rows with long clid’s. Resulting in additional column shifts on certain rows.
OK, I did some more testing and found where php suffers when allocation data.
This is time consuming in php:
$data = $data . $csv_line[$i] . "," ;
$data = $data . "\n";Execution time: 43.395808935165 seconds
By replacing that with:
$data .= $csv_line[$i] . "," ;
$data .= "\n";Execution time: 0.1939640045166 seconds
The speedup in php is enormous.
So, restore the functions.inc.php, then change according to this:
Index: functions.inc.php
===================================================================
--- functions.inc.php (revision 12476)
+++ functions.inc.php (working copy)
@@ -206,12 +206,12 @@
$csv_line[$i] = "\"" . $csv_line[$i] . "\"";
}
if ($i != count($csv_line) - 1) {
- $data = $data . $csv_line[$i] . ",";
+ $data .= $csv_line[$i] . ",";
} else {
- $data = $data . $csv_line[$i];
+ $data .= $csv_line[$i];
}
}
- $data = $data . "\n";
+ $data .= "\n";
unset($csv_line);
}
cdr_download($data, $fname);That will speed up execution, it should produce the same output as before.
As for download all, if you to download 100,000 records the memory in apache/php will run out.
I will look into that to see what I can do.