Call History causes extremely high cpu loading

Look under
System Settings - CDR Settings
Are you still writing to csv? If you are that will kill your cpu trying to look at that file. you should only use SQL.

Look under
System Settings - CDR Settings
Are you still writing to csv? If you are that will kill your cpu trying to look at that file. you should only use SQL.

Look under
System Settings - CDR Settings
Are you still writing to csv? If you are that will kill your cpu trying to look at that file. you should only use SQL.

Thanks a lot for the hint!!!
Under CDR settings -> "When displaying records select them from" I had none selected.
Just selected "MySQL" and it started to work!

I ran into the same issue as xxot did... and I have a couple of MTE servers setup. Running Thirdlane 6.1.1.12 and Asterisk 1.6.2.11.

On one of the servers the Check boxes are Enabled for both Write to CSV and Write to MySQL.

On the other system I have Enabled for Write to CSV and Disables for Write to MySQL. When I click Enable for Write to MySQL and hit SAVE... the screen just reloads without any changes... Still Enabled for CSV and Disabled for MySQL.

These systems were built from ISO and it appears that the correct databases, tables, usernames, etc are in MySQL.

Let me know if you have any ideas. Thanks.

consider getting off the unsupported broken version of asterisk and moving to 1.8.11-certified branch

Erik

That is something to consider and our next MTE build will be 1.8... but are you really sure that the inability to save this selection in the Thirdlane console has to do with the version of Asterisk? Not MTE or MySQL?

check the file and you're going to find that everything is actually working, it is just the gui's ability to see the module running that changed. the name of the asterisk module changed and thirdlane fixed it to recognize the correct name in order to display the correct radio button

Looks like the server with the trouble had been updated without the Asterisk Add-Ons being updated...

Seems like these are the 2 important files and they are both in Add-Ons.

app_addon_sql_mysql.so
cdr_addon_mysql.so

Recompiled everything from scratch. Rebooted the system. Checked System Settings > CDR Settings and Enabled the MySQL and hit Save. Once that is done the system updates Modules.conf to load => cdr_addon_mysql.so... at that point you need to restart Asterisk... or in my case I just did another reboot.

Now it comes up fine and I can see all the CDR info via MySQL. Thanks for your help.

you dont have to add the load statement if you are autoloading all modules. in asterisk 1.8 the add-ons is not a separate download.

Yes, Auto load is on... but after the upgrade and reboot the modules.conf file actually has:

noload => cdr_addon_mysql.so

So by making the change, saving it, and rebooting... MTE switched it to the load statement. I would assume there is some reason MTE is explicit about these modules even though the Auto load statement is on.

Good to know about the 1.8 not needing Add-ons... I did notice that the Add-on updates stopped at 1.6.x.

why would an upgrade change your modules.conf ? you didnt do a 'make samples' did you? no upgrade should ever change anything in /etc/asterisk once your initial dialplan has been written

I think this is just poor wording on my part... I don't think the upgrade changed anything in Modules.conf.... I think because it was Disabled in MTE it was also

noload => cdr_addon_mysql.so --- in modules.conf

Then when you Enable it in MTE it appears MTE re-writes modules.conf to be

load => cdr_addon_mysql.so

Since MTE seems to be changing modules.conf it seemed like the best place to do the update was from the MTE GUI.