Data logging window disappeared at startup

[choc-a-holic]

Have pm'ed details to you 

[gabba]

Have done some hunting around but so far no luck. I dropped the clientraw file into an editor and all seems fine there, although I didn't check it down to data field level.

I dug out some reporting, which I've attached. As an example of a successful file read I've included mine. What it suggests is that it locates the file correctly but for some reason doesn't want to read it. Anyone with any other thoughts?

So at this stage I'd like to look at the file being uploaded to an account on this server. I can have a better play with the script and also check a few other things  that may point to something

[JennyLeez]

Gabba I am pointing you back to beteljuice's post:

Something weird going on, but I don't know what !

The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!

The scripts look for and remove the leading 0d0a but from this server for some reason the check method isn't recognizing the 0d0a ?

If I rewrite the check method a different way it works.

So there is the reason why. Very strange as for years on her server it has been fine. Since the PC crash and upgrade it has not. The clientraw.txt is fine Gabba. I have compared each data entry against Brian's clientraw.txt as he is running the same version.

Now while betel can fix the Data Summary script it is not going to fix the Map script.

I can have a better play with the script...

You also better be careful with your playing...lol

Tomorrow we will test the clientraw.txt on another server.
I will let you know how we get on.

Sending the second instance of her clientraw to the forum server may be our only option.

Cheers.

[gabba]

Something weird going on, but I don't know what !

The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!

The scripts look for and remove the leading 0d0a but from this server for some reason the check method isn't recognizing the 0d0a ?

If I rewrite the check method a different way it works.
So there is the reason why. Very strange as for years on her server it has been fine. Since the PC crash and upgrade it has not. The clientraw.txt is fine Gabba. I have compared each data entry against Brian's clientraw.txt as he is running the same version.

Now while betel can fix the Data Summary script it is not going to fix the Map script.


Tomorrow we will test the clientraw.txt on another server.
I will let you know how we get on.

Sending the second instance of her clientraw to the forum server may be our only option.

Cheers.
[/quote]

More random thoughts...
Does Brian's file also have the 0d0a hex character? If I read it right the 0d0a character appears at the start of the txt string? It seems strange that WD would start adding that code now, on that PC, after a rebuild, and presumably not on anyone elses who have upgraded to that version (or at least this is the only instance where the code to remove the hex code is being executed) - so it's rather odd!

I've got older versions of WD here - I wonder what would happen if we downgraded?

It's probably worthwhile us both doing the server tests. While the scripts are based on the same code (I believe) the servers will be configured differently. I know I'm clutching at straws a bit going down the server route, but the worst thing that can happen is that we both validate what each other find ;-)

Cheers

[Weather Display]

0a0d are control characters, line return and carriage return
but WD does not add those, I suggest the server is adding those

[beteljuice]

It would be / is from the server.

It is an optional prefix to the 'magic number(s)' of whatever the server has done. (eg. gzip and / or block encoding)

Looking at the binhex string following the headers everthing looks OK.
... but the scripts fail to do a simple search and remove operation for some unseen reason !

[Weather Display]

it could be that somehow the server is set to ascii mode or similar?

[gabba]

Yes - that was my thinking too - I haven't seen the FTP log yet , but should hopefully be able to tell when I get home tonight, by looking at the FTP log on the (this) server side

[gabba]

Another curly one - we are using the panel in WD that allows two FTP servers to be set up.

The first FTP server works fine, and I can browse to the clientraw.txt and see it

The second FTP server gets a file of 0KB, and when it's opened up it is blank. It occasionally (roughly hourly) gets a valid file, which is then overwritten by a blank file about 10 mins later as per the ftp schedule.

Has anyone seen this behaviour before?

I've had mixed results in using the files I have managed to get on the server, so no final solution yet

[Weather Display]

if you can , set to use passive mode and set to rename the file too on the server

[gabba]

passive mode seems to have worked. Just doing final testing, but it looks like it works uploaded to this server, but not if the file is pulled from the other server

If that's the case we can do some troubleshooting from there, but at least we have a working solution.

Next step I think is to do a compare between the two setups and the two logs. If the are largely identical then I think the original FTP server would be the problem.

Cheers and thanks

[Weather Display]

I put my money on a problem with the server

[JennyLeez]

Yep agree which is what I advised choc-a a week ago.

Choc-a I know your server does not want to know about this but perhaps you could link them to this thread and then they can read down for themselves.

Your clientraw.txt has been uploaded now to 2 other servers and our scripts can read it without a hitch.

These same scripts are reading hundreds of clientraw.txt files around the world. Tell them it is not our scripts but what they adding at their end.

Give this to your server:

The content is gzipped which is not a problem.
This is prefixed by hex 0d0a, which shouldn't be a problem but is !!

0a0d are control characters, line return and carriage return
but WD does not add those, I suggest the server is adding those

It would be / is from the server.

It is an optional prefix to the 'magic number(s)' of whatever the server has done. (eg. gzip and / or block encoding)

Looking at the binhex string following the headers everthing looks OK.
... but the scripts fail to do a simple search and remove operation for some unseen reason !