Call stats auto download - Poor design

[medoneit]

I strongly disagree with the paradigm of the Auto Download feature.

I wish to report on my calls at the end of the day, but given the way the feature works, I have no way of guaranteeing that I have all calls available to me at the end of the day.

My best bet would be to set the Number of Call Records to 50. But if I did this, there is a good chance that 50 call records could be generating within the same minute, thereby overwriting the previously download file (On the TFTP server, the file names are time based, accurate to the minute).
On a real big environment, this *might* even occur if the threshold is set to 200!

Because of this, I am going to be forced to run the report for i.e Monday, at 12 pm Tuesday, as this is the only way I can be sure that all records have been downloaded for Monday.
And because of that, I have to implement a whole bunch of date smarts in my code that I shouldn't need to.

Why, on earth, am I unable to schedule the auto download?

What was the intention of the design?
I would suggest a scheduled download time. But I presume that it was ecided that the size of the log file was an issue for some reason, therefore I suggest an option to limit 'MAX pending downloads'.

Michael.

[hrant]

The intent was to have a simple and robust design with predictable number of CDRs stored in the file. In time based design the number of CDRs in a file is unpredictable and there is a risk that the allocated space will not be sufficient for storing the file on Quadro before uploading it to external server.
As far as the evolution of the automatic CDR upload feature is concerned then we've changed the naming format of the uploaded files to include seconds. Also, the time based archiving of CDR files will be possible, with their manual or automatic upload to external server . The feature will be available first on QX1000 and QuadroM32x. The test images can be provided upon request.

[medoneit]

Thanks hrant, sounds good. For now I set the dump to every 100, and will code appropriate logic.

I won't try the beta image... We have an M32, but no room for testing firmwares

Will the time based functionality include support to dump the file off-schedule if needed, based either a calculated memory limit, or a user set max records?

[hrant]

There are two separate processes: time based or CDR number based archiving and uploading the files to external server. The first process will archive and store the files on Quadro. The memory size allocated to archived files is configurable from GUI and similar to that of voice mails. If there is no space anymore, the oldest file will be kicked out.
The uploading process works if "send and keep" or "send and delete" archive file uploading options are selected. In both cases the file will be uploaded immediately, as soon as it is built. However, in case if the internet connection is temporarily down, the upload might be delayed. The files which are not uploaded yet, will not be deleted from archive and user may download them from WEB GUI of Quadro.

[medoneit]

My TFTP server disapeared for 4 hours for some reason.

During that time, the quadro attempted download but failed.

All call records however, still got marked as downloaded.

How can I re-download those that did not download?

"auto download statistics failure Downloading statistics failed. "

[medoneit]

Ok what I did was

1) Directly download from the succesful calls page
2) Open in excel, and insert the first column "Call type". The file format now matches the auto downloaded files, so my parser is happy.
3) Cut out records that I already have ( cut out all records from overnight, as these are the ones that were lost: 5:31pm to 11:02 am

The only difference between the auto doanload tab file, and the one downloaded from Succesful Calls, is the first column "Call Type" is missing, and the times are only accurate to the minute.