Agent activity pause code with 0 pause time

[webudo]

I'm using ViciDial VERSION: 2.14-773a BUILD: 201101-1056 (SVN 3309) installed from ViciBox v.9.0.3 200630-2117 ISO.

When pulling an agent's activity report, there are some times when there's no logged PAUSE time on the same line of the PAUSE CODE like que example below:


As you can see, the PAUSE CODE "TOILLE" shows 0 PAUSE time, and the real PAUSED time is logged on the next agent's event (802 seconds).
This 802 seconds are not counted on the Agent Time Detail report.
This only happens sometimes and we're unable to reproduce it or to know why this is happening.

Any ideas are welcome.

Thanks!

[williamconley]

pause, choose pause code, log out immediately.

log back in. but do not resume. wait 15 minutes. then resume.

pause code chosen would have zero seconds (maybe 1 second) and the next call would have pause time but no pause code.

just a guess.

thanks for posting your system specs!

[webudo]

Thanks for your quick reply @williamconley

We tried as you suggested, but times are reported correctly doing that.

[williamconley]

Next suggestion would be to find out if the error lies in the report when it gathers the logs for display or in the log entry itself (likely as it was created).

Check the logs for a "good" vs "bad" outcome and see if there is a difference, and if you can decipher whether the difference is likely an error in recording the log.

[webudo]

Database table show's exactly the same entries (with error). So the problem gets generated during data writing/collecting

[williamconley]

Now you'll need to either catch one "in the act" or scour the log files to decipher how this happens. /var/log/astguiclient logs may have your bug.

Of course, upgrade before you begin. Sometimes these problem are fixed by someone else, trying to fix something seemingly unrelated, and you could have solved the problem without the chase just by upgrading. Always a good first reflex.

Next up, see if you can find a pattern to:
* The occurrences
* The "bad records"

Obviously the search for the bug would be assisted if there were some sort of predictability in the occurrences. Call length, server, agent, pause code pattern, anything will do.

If the bad records all have the same pattern, such as being "the one right after a blank pause entry, but having pause time when they shouldn't" it's entirely possible to create a bandage script.