wrong duration in operator performance

[Kristijan Mikulec]

Hi,

There is problem with operator performance tool.
Displayed data is inaccurate. For some reason sometimes operators have abnormal call timings.
Example:
Operator for this shift has 20h40m in call time, but thats imposible. Real in call time for that operator was 3h49m.
Is there any fix for that problem ?

[Adam Zammit (adamzammit)]

Can you locate the call record in the database that is causing this?

That would help determine what is causing the calculation error.

[Kristijan Mikulec (kmikulec)]

Hi,
here is screenshot of another example.

[Kristijan Mikulec (kmikulec)]

and here is screenshot of real duration

[Kristijan Mikulec (kmikulec)]

these two screenshot are for same operator on same day.
Sometimes there is even bigger problem. In call and call_atempt tables are inserted wrong values.
E.g. Call start is yesterday at 19:45 and call end is today at 13:26. So it looks like operator is on call whole night and half of day. In that situation I have to find that call in asterisk database look for real start and end time and update call and call_attempt tables.

[Adam Zammit (adamzammit)]

Thanks for that - the query you have used isn't identical to what the shift reports will use to calculate as all dates/times in the database are stored in UTC.

I think what is happening is that very long calls are being recording in the database due to calls or call attempts not being closed, and then being closed the next day / time the operator is logging on. Can you please check the call attempt records or call records in the database where they are very long, and see if they are the "last" call attempt for that operator for that day/ shift?

If so, it is possible the operator is not ending their calls properly, or there is something else preventing the correct "end of call" code being executed.

If this doesn't fix the issue, an alternative may be to specify a "max" call time (eg 4 hours or so) and then update the end_call and end_call_attempt functions to record a specified call time if it is over this threshold. This would allow operators to not correctly end some calls but still have consistent data.