Talk time transfer in wait time

[alexmeunier]

Hello,

We have a problem with the call time statistics. This is undoubtedly related to the daily task AST_cleanup_agent_log.pl.

When we look at the talk time for the current day, the data matches the actual call time. However, when we look at the same calls the next day, the talk time is transferred to the wait time.

See some examples in the attached file.

Thanks for your help.

Alexandre



--

Version: 2.14-926a
Build: 240805-1738
SVN Version: 3864
Asterisk v.18.18.1
MariaDB: 10.5.22
Apache 2.4.57
PHP 7.4

[williamconley]

Moved to Support board (not a "General Discussion" topic).

What installer did you use? Are you using a language other than the english web pages (since I saw some French in there I have to ask). If so, have you tried accessing with English to see if there's just a typo in a translation?

[alexmeunier]

Thank you for your prompt feedback.

The problem is not related to the display (typo or language) since the data in the database is affected.

[williamconley]

The problem is not related to the display (typo or language) since the data in the database is affected.

Unless you've looked in the log tables and have seen the data has been changed. I wouldn't assume that before verifying, of course. There are some nightly routines that clean up data, but I've never heard of it reversing talk and wait.

Also I did not get a reponse, just a side-step to the question. This (in my experience) tends to precede the statement "oh! crap that WAS the problem!"

I also note that 2/28 and 2/27 did not move. So is it possible you ran some sort of routine which altered the data? Did you install or code any new scripts/reports (anything?) between 2/28 and when this report was run with the single day altered?

[alexmeunier]

The 1st and 3rd tables were generated on 2025-03-04. So, for the day itself, we see time for talk time.

Tables 2 and 4 were generated the following day (2025-03-05). We can see that talk time is now 0 and has been transferred to wait time.

In the database, talk time is set to 0 for all records except those for the current day.

Data for the 27th and 28th were already at 0 in the 4 tables, as there was no data for the current day.

We installed it manually based from this procedure https://github.com/carpenox/vicidial-in ... 9-ast18.sh

No custom script or addons other then that has been installed.

Here is the list of cron jobs:

Code: Select all

0 0 * * 0 /usr/bin/find "/var/spool/asterisk/monitorDONE/MP3" -name "*.mp3" -ctime +180 -delete
30 2 * * * /usr/bin/certbot renew --quiet
* 1 * * * /usr/share/astguiclient/ADMIN_audio_store_sync.pl --upload --quiet
0 2 * * * /usr/share/astguiclient/ADMIN_backup.pl
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl --MIX
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl
1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58 * * * * /usr/share/astguiclient/AST_CRON_audio_2_compress.pl --MP3 --HTTPS
* * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl --cu3way
* * * * * /usr/share/astguiclient/AST_manager_kill_hung_congested.pl
* * * * * /usr/share/astguiclient/AST_vm_update.pl
* * * * * /usr/share/astguiclient/AST_conf_update.pl
11 * * * * /usr/share/astguiclient/AST_flush_DBqueue.pl -q
33 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl
50 0 * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl --last-24hours
* * * * * /usr/share/astguiclient/AST_VDhopper.pl -q
1 1,7 * * * /usr/share/astguiclient/ADMIN_adjust_GMTnow_on_leads.pl --debug
2 1 * * * /usr/share/astguiclient/AST_reset_mysql_vars.pl
3 1 * * * /usr/share/astguiclient/AST_DB_optimize.pl
2 0 * * 0 /usr/share/astguiclient/AST_agent_week.pl
22 0 * * * /usr/share/astguiclient/AST_agent_day.pl
24 1 * * * /usr/bin/find /var/spool/asterisk/monitorDONE/ORIG -maxdepth 2 -type f -mtime +1 -print | xargs rm -f
30 1 1 * * /usr/share/astguiclient/ADMIN_archive_log_tables.pl --DAYS=45
28 0 * * * /usr/bin/find /var/log/astguiclient -maxdepth 1 -type f -mtime +2 -print | xargs rm -f
29 0 * * * /usr/bin/find /var/log/asterisk -maxdepth 3 -type f -mtime +2 -print | xargs rm -f
30 0 * * * /usr/bin/find / -maxdepth 1 -name "screenlog.0*" -mtime +4 -print | xargs rm -f
25 0 * * * /usr/share/astguiclient/AST_DB_dead_cb_purge.pl --purge-non-cb -q
1 7 * * * /usr/share/astguiclient/AST_dialer_inventory_snapshot.pl -q --override-24hours
* * * * * /usr/share/astguiclient/AST_inbound_email_parser.pl


[williamconley]

Getting closer. You posted Vicidial Report screens, not tables.

Let's see the field data for a single record that was different from one day to the next. From the table in the database. Then we can drill down to which script(s) screwed up the data and/or see if this same event occurs on a ViciBox installed system (I can't imagine why it would be different, but it would certainly be worth noting if it were!!)