Search Statistics Report Question

[nccsts]

Hi,
I'm having a problem generating search reports inside of Zoom. This is the second time I've experienced this. Basically, when I go to generate a report,, the Zoom Report tool is no longer able to identify the "Top 10 Searche phrases" nor the "Top 10 No Result Phrases" for the last month. It can pull up info from before a certain time, but can't bring up the last month of data, even though the data is clearly there in the log file if I go to Notepad and open the file, so the log is getting written fine, it's the report tool that's choking. I thought the log file might be getting too big, so I chopped the size by elimininating records at the beginning of the file (oldest dates), but the problem remains. The file size is only 500K, and I've run reports successfully before on files that size. Any suggestions would be appreciated. I'm using Zoom 4.
Ky Herreid

[David]

Can you give us the URL to the file or E-mail us the file so that we can check it out. E-mail is zoom [at] wrensoft [dot] com

Can you also give us the date ranges that you entered, which produce the unexpected results.

------
David

[nccsts]

I went ahead and sent you the file yesterday morning. Thanks for taking a look at it.
Ky Herreid

[Ray]

We've had a look at your log file, and found that the problem is caused by an extra blank line that was added to the log file between 2005-03-15, and 2005-03-16. This blank line caused the statistics reports utility to stop parsing the file, so that all statistics were calculated up to only this point in the log.

Was the log file opened in a text editor or modified in anyway at some point? Perhaps you had opened the file in Notepad and accidentally saved the file with an extra blank line.

If you remove this blank line (found between the aforementioned dates) from the log file and run it through the search statistics utility again, it should successfully analyse the entire log file.

[nccsts]

Dear Raymond,
Thanks for looking into this with me. I took your suggestion and narrowed down the problem. It does appear that a carriage return or some non-ascii character was inserted at the end of one line (end of line 5 of the now shortened log). Since I've never opened it and resaved it and uploaded it back to the server, I don't know how that would have been inserted on my end.

Be that as it may, when I remove the offending character, or even the whole line, or even the whole line and some succeeding lines, the zoom statistics report now hangs while a message reads "Parsing File" and Zoom has to be terminated through task manager. This is interesting, because the lines immediately after the one with the funny characters look syntactically fine.

I've taken the liberty of emailing you a much smaller log file. To recreate the probelm, choose the third item "Searches per Day"m choose "Date Range" and choose 3/15 to 3/16 or whatever.

The offending line is the second of the following three (I've hashed out the IP addresses below--BTW, we are a science info site):
~~~~~~~~~~~

2005-03-15, 19:33:46, ###.###.###.###, "human without sweat glands", Matches = 361, OR, PerPage = 10, PageNum = 0, No cats, Time = 5.933
2005-03-15, 19:38:13, ###.###.###.###, "human without sweat glans", Matches = 0, AND, PerPage = 10, PageNum = 0, No cats, Time = 7.219

2005-03-15, 19:38:19, ###.###.###.###, "human without sweat glands", Matches = 0, AND, PerPage = 10, PageNum = 0, No cats, Time = 2.146
~~~~~~~~~~~~~
Thanks again for the help.
Ky Herreid

[Ray]

Had a look at your new log file and this didn't happen for me. Are you using the latest build of Zoom (Version 4.0 build 1016?) If not, you can download this from http://www.wrensoft.com/zoom/whatsnew.html

I presume the file you sent me was the one that was supposed to have caused Zoom to crash. Or did you mean that I had to remove the offending line myself etc.?

Nonetheless, I've tried loading it as it is, as well as removing the extra blank line that is still in your new log file, and in both cases it did not hang.

We have been improving this in Version 4.1 (which we're hoping to release in a few weeks time), and it should be more tolerant of unexpected characters etc. in the file (such as the blank lines). However, if you do find something that 'hangs' Zoom, then let us know, as this should never happen.

It's also a wonder as to how they got in the log file in the first place. What have you used to look at the file? Have you done it in a FTP client which may have automatically re-uploaded the file for you upon opening it in Notepad for viewing/editing (which is not uncommon). Were any changes ever made to the search script (search.php, search.asp, ...)?

[Anonymous]

I was using 4.0 Build 1001. I'll try the latest build and let you know later.
Thanks!

[nccsts]

Okay, problem solved. I upgraded, but actually that's not what was causing the hang. When I copied and pasted part of the log to troubleshoot, I clipped the carriage return at the end of the last line of the log file. It didn't occur to me because you don't see carriage returns when you open it up in Notepad. I don't know if you can work it into a FAQ, or perhaps you think the problem is too isolated to worry about, but it would have saved me an hour or two of fiddling to know that the absence of a carriage return at the end of file would cause Zoom to hang while parsing. When I think of it now in hindsight, I understand why this would occur, but I wasn't thinking of it when I was banging my head.

With regard to your questions, I've only ever looked at it with Notepad, and I don't THINK (though I couldn't swear to it) that I've ever upoladed it back to the server after viewing it in Notepad (FWIW, I use WS_FTP as FTP client, but I don't think it's relevant). In any event, now that I know what to look for, i.e. extra carriage return in the middle of the file (and/or the absence of a carriage return at the end of the file) I should be all set.

Once again, thatnks for your help with this, and my gratitude to you and your team for this useful product and support.
Sincerely,
Ky Herreid

[Ray]

Glad to hear the problem's been solved. The log file was never really designed to allow for user editing, so the statistics report tool does not have much tolerance for log files which have even the slightest syntatical difference.

Nonetheless, it should never 'freeze up' on a file like it has, and we have fixed this bug in the upcoming version (4.1). It will also be more tolerant of any other 'errors' in the log file.

[nccsts]

I understand.
I look forward to Zoom 4.1!
Thanks again,
Ky