I checked the code, there is a timeout enable to the FTP transfer client so not sure what your seeing


try enabling the FTP debug feature and next time it hangs, report back what phase of the transfer its stuck at ...

I've see this happening at 2 other locations:
http://members.cox.net/wennfred/GTVIEW/ ... n_Save.png
usually recovers in several hours, somehow
and
http://energy-alternatives.com/GTview/G ... n_Save.png

What happens, is the transfer seems to begin, the remote file is zeroed somehow, and no real .png upload happens.
I have links to these monitors on my 2nd page, and it's real easy to see when one goes down. I've tried to force a d/l of the image, but it's zero bytes, not a missing image, just an empty file. If it was actually gone, I'd expect a broken link browser error, not a image can't be displayed error.

http://www.mike-burgess.org/PVinfo_2.html

--

"The faulty premise is that privacy is about hiding a wrong."
Bruce Schneier

Yep, I have been having alot of problems with that so what I do is I go onto the FTP site and delete the PNG file hoping the next one is upload and corrected. If it has the Zero bites, it wont work.

I rebooted the computer, deleted the Zero Byte PNG file and Im still uploading a PNG file with no info, what can I do next?



Fred

Another thing I've noticed, is the uploaded .PNG file on the server, sometimes has a "weird" name : GT_Screen_Save.png?1187282131076 and I don't know if the server is adding the ?1187282131076 to the filename, or the browser does it. The #'s are different, and I haven't found a pattern.

So, I got back home and enabled the FTP Debug screen to see what was going on.

the right screen locked up (I have two instances of GT-view running on the same machine) first, and here is the output.

http://solar.johnjan.com/stuck_xfer_right_display.PNG

so, I opened up my FTP client, and tried to look at my GoDaddy webhost directory, and I was locked out. It said that I could not log in while another process was logging in. (I used SmartFTP as my client).

I wonder if this lock-up behaviour is only happening to people running more than one instance of GT-view at a time, and the two are trying to log in simultaneously to write their file.

To test this, I stopped both of my GTview instances. I have the programs in separate directories (gtview\left, and gtview\right). I started the \left program first. I edited the FTP upload interval to exactly 300 seconds. Then I waited for an upload to occur. Once the upload happened, I waited 2 minutes, and started the "right" instance of GTview, and set it to a 300 second interval. I figured this would give each program a chance to log in, upload, and log out before the next instance tried.

It's been running for over 24 hours without a hang-up. I suppose I will have to write a batch program to autostart these two instances delayed by 150 seconds on reboot. Today, I use autologin, and the two shortcuts are simply in my STARTUP directory. I had them originally set to upload every 589 seconds on left, and 610 seconds on the right. But this offset alllowed random occasions when they both uploaded at once.

I will let you know if it hangs up again.... I am crossing my fingers that it's fixed.

John

It hung up at 12:32am last night, (or that is the time-stamp of the zero byte file on the godaddy webhost server.)

So, the offset between the two uploads did not keep the hang from occuring.

My next effort, is to stop using the PNG upload, and just write an excel macro to summarize the daily log file, and post a graph of that to the web every 30 minutes or so.

John

I cant get GView #2 to post the PNG file any more. All else failed.


Fred

sorry to hear some of you are having issues,

I have a single old 500mhz pc monitoring 3 GT inverters. I have three copies of GT-View running each in ther own folder uploading to godaddy without issue

Couple of things I do, I have the interval different so I don't get the concurrent login issue, I have the file names of the png files different and on my display script, I cache the pngs so if an internet user happen to displaying the image there isn't a lock conflict, IE an update to an actively displayed image. Also if there is a conflict, instead of just keeping a broken ping image displayed, the script will retry in one second ( instead of the 120 seconds ) to update the image

The script is here http://www.solar-guppy.com/realtime_status.htm

Here is an example of how to prefetch :

<title>Woodwind Hills Solar Status</title>
<script language="JavaScript">


function prefetch_pool() {

cached_image_pool = new Image();
cached_image_pool.scr = "http://www.solar-guppy.com/downloads/FishBowl_Current_Pool.png";
setTimeout("swap_pool()",5000);
}

function swap_pool() {

document.fishbowl_pic_pool.src = cached_image_pool.scr;

}

function woops_pool() {

prefetch_pool();
}

</script>
</head>

<body topmargin="0" leftmargin="0">

<img name="fishbowl_pic_pool" src="http://www.solar-guppy.com/downloads/FishBowl_Current_Pool.png" onError="setTimeout('woops_pool()',100);" onLoad="setTimeout('prefetch_pool()',120000);" width="557" height="185">

</body>
</html>

Also, if you want to make the status window a fixed size, call it from another html file ( like your main index file ) like so


<Script Language="JavaScript">
function openwindowlink() {
newwin = window.open("http://www.solar-guppy.com/realtime_status.htm","Solar","height=555,width=557,location=0,menubar=0,resizable=0,scrollbars=0,status=0,titlebar=0,toolbar=0")
}

<font face="Verdana">Real Time Status</font></b> of our dual 2900 watt arrays via GT-View
<a href="JavaScript:openwindowlink()">REAL TIME STATUS</a> *, </p>

Did you chmod 777 the file on the server before deleting? ... or try a new file name ... could be something odd is locking the file on the server