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!!)

[alexmeunier]

Hello,

Here are two screenshots of the vicidial_agent_log table. The first was taken on 10-04-2025 and the second on 11-04-2025.





As you can see, the talk_time for the day of 10-04-2025 is transferred to the wait_sec column the following day.

What could be causing this problem?

Thanks for your help.

Alexandre

[williamconley]

My guess, if you're the only person experiencing this, is that you have a Really Cool archiving script or something else custom running and somebody screwed up a line in the code.

But I'm just guessing.

Next stage: Watch the next example every day until you find out how many days it takes to change.

Then watch on that day for the next example until you find out what time it happens.

Then check your cron jobs on all your servers. Unless you have allowed external access to the DB, of course, in which case it may be on some other server. You could search for that table and/or field name through all your custom scripts, too. If you don't allow external DB access, it's gotta be in there somewhere!

[alexmeunier]

Hello,

We have noticed that the problem seems to come from the vicidial_agent_log table. In this table, the dispo_epoch value (call end time) equals the talk_epoch value (call start time) for the majority of records where talk time is normally present. So, when the Cron task AST_cleanup_agent_log is executed, the difference between the two values (0) replaces the talk time and ends up in the wait time.

Why is the dispo_epoch value wrong?

Please note that our agents use ViciPhone. Any links?

Also, we don't use any custom script.

Thanks a lot,

Alexandre

[williamconley]

Details, cool.

the dispo_epoch value (call end time) equals the talk_epoch value (call start time) for the majority of records where talk time is normally present. So, when the Cron task AST_cleanup_agent_log is executed, the difference between the two values (0) replaces the talk time and ends up in the wait time.

Is this for all records? Or some?

Have you determined why the dispo_epoch and talk_epoch are identical? Obviously those two epoch times should be different on any call that actually connected to the agent, by at least one second.

What is your asterisk version (literal, copy-paste! include punctuation if present!) from /etc/astguiclient.conf and from admin->servers for the server(s) in question.

How did you install your system (Full installer with Version and/or link to instruction set if you did not use a Vicibox .iso)?

Is it possible your AST_cleanup_agent_log script is the wrong version or has code it in expecting a different db_schema or asterisk version?

Can you try a single sample call to track these values and see why they are wrong? Trace it script by script ...