Launchbase Syringe/Ares updating problems

[MRMIdAS]

Well, LB tries to DL Syringe, it gets a 0b .exe

also it's refusing to access the ares RSS feed.

[Renegade]

SVN version is 112 KB for me.

I am not sure which feed exactly it's trying to access, but server side, everything seems to be fine.

[MRMIdAS]

SVN version is 112 KB for me.

I am not sure which feed exactly it's trying to access, but server side, everything seems to be fine.

well I've tried it on 2 machines, and both have come up with the same 0b file.

very weird

[Marshall]

Can you try again and post the LaunchBase.log entries from that session?
Is anybody else having the same problem?

[MRMIdAS]

Yep, it's still doing it.

[DCoder]

I'm getting the same. Oddly enough, if I unpack the tar manually into the same folder syringe uses, it leaves the executable and the temp folder lying around, as opposed to removing it when I don't do anything manual. Either way, the log only mentions moving of the license file, not the executable. Seems like you're either not extracting all files, or the placeholder 0 byte executable messes things up.

Code:

2009-05-03 11:43:59  Checking for updates to Syringe via RSS feed.
2009-05-03 11:44:05  Parsing RSS feed.
2009-05-03 11:44:05  Syringe update available. User revision: 0. Latest revision: 10.
2009-05-03 11:44:06  Downloading "http://svn.renegadeprojects.com/dl.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&isdir=1" to "F:\games\yr\LaunchBase\Resource\syringe.tar.gz"
2009-05-03 11:44:19  Download complete.
2009-05-03 11:44:19  Deleting "F:\games\yr\LaunchBase\Resource\syringe.tar"
2009-05-03 11:44:19  Moving "F:\games\yr\LaunchBase\Resource\msvc.r10\license.txt" to "F:\games\yr\LaunchBase\Resource\Syringe.txt"
2009-05-03 11:44:19  Syringe update complete. Updated to revision 10.
2009-05-03 11:47:59  Deleting "F:\games\yr\LaunchBase\Resource\msvc.r10"
2009-05-03 11:47:59  Checking for updates to Ares via RSS feed.
2009-05-03 11:48:02  Ares update check failed - failed to access RSS feed.

[Renegade]

D has just run that thing again for the enjoyment of our logs, and the server shows the following happening:

Code:

1.      xx.yy.zz.aa - - [03/May/2009:11:04:59 +0200] "GET /rss.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 206 2655 "-" "Microsoft URL Control - 6.00.8862"
2.      xx.yy.zz.aa - - [03/May/2009:11:05:01 +0200] "GET /rss.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 206 2655 "-" "Microsoft URL Control - 6.00.8862"
3.      xx.yy.zz.aa - - [03/May/2009:11:05:03 +0200] "GET /dl.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&isdir=1 HTTP/1.1" 200 14600 "-" "Microsoft URL Control - 6.00.8862"
4.      xx.yy.zz.aa - - [03/May/2009:11:05:06 +0200] "GET /dl.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&isdir=1 HTTP/1.1" 200 79933 "-" "Microsoft URL Control - 6.00.8862"
5.      xx.yy.zz.aa - - [03/May/2009:11:05:26 +0200] "GET /rss.php?repname=Ares&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 200 8930 "-" "Microsoft URL Control - 6.00.8862"

Code:

1.      xx.yy.zz.aa - - [03/May/2009:11:29:55 +0200] "GET /rss.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 206 2655 "-" "Microsoft URL Control - 6.00.8862"
2.      xx.yy.zz.aa - - [03/May/2009:11:29:58 +0200] "GET /rss.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 206 2655 "-" "Microsoft URL Control - 6.00.8862"
3.      xx.yy.zz.aa - - [03/May/2009:11:30:00 +0200] "GET /dl.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&isdir=1 HTTP/1.1" 200 14600 "-" "Microsoft URL Control - 6.00.8862"
4.      xx.yy.zz.aa - - [03/May/2009:11:30:03 +0200] "GET /dl.php?repname=Syringe&path=%2Freleases%2Fmsvc%2F&rev=0&isdir=1 HTTP/1.1" 200 79932 "-" "Microsoft URL Control - 6.00.8862"
5.      xx.yy.zz.aa- - [03/May/2009:11:30:25 +0200] "GET /rss.php?repname=Ares&path=%2Freleases%2Fmsvc%2F&rev=0&sc=0&isdir=1 HTTP/1.1" 200 8930 "-" "Microsoft URL Control - 6.00.8862"

I have checked all three links shown, and they're all fine, specifically:

• The Syringe download link does deliver the full directory content including a 114176 byte Syringe.exe
  
• The Ares RSS definitely works
  

So whatever problems you're having are not server-side.

An interesting thing D pointed out is that, not only are you querying each url twice, but you are getting a differently-sized response in line 4 compared to 3, and I noticed you're getting an almost-equal, but off-by-one-byte response for the two 4s.
Theory:
Is it possible that LB behaves this way:

1. Query RSS
   
2. Query RSS
   
3. Start Download 1
   
4. Create File 1
   
5. Start Download 2
   
6. Create File 2
   
7. Detect Download (1) is done
   
8. End Downloads (1 & 2) because Download (1) is done
   
9. Extract File 2
   
10. Fail
    

Maybe it chooses File 2 because it's newer, or because it overwrote File 1, point is: Maybe it's trying to download twice, aborts both downloads when the first one is done, but trying to extract the partial file?
Does the issue persist when the number of downloads is reduced to one?


As for Ares's RSS - interesting is that you're getting code 206 for the Syringe RSS (Partial Content), but 200 for the Ares one...maybe MS URL Control doesn't expect that?

206 Partial Content
The server is serving only part of the resource due to a range header sent by the client. This is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

Since the Syringe one is the one being read fine, it can't be that 206 startles it...and 200 is "OK", after all, and used by the dl.php ones as well, so there should be no problem with that. Only thing I can think of is that the switch between 206 and 200 confuses it, somehow.

(In any case, it'd be nice if you queried each item only once...think of the server )

[Marshall]

Sorry for the delay on this guys, I'm pretty sure I've fixed the problem - it was a case of arsebrain on my part, that led to the syringe executable not being saved.
I've fixed that and am trying to upload the new Launch Base now, however I'm getting an error trying to connect to the FTP. Renegade, I've PM'd you about that.

I'll upload the new version as soon as I am able.

Edit:
Although the Ares RSS feed issue might not be fixed yet, I'm still looking at that but am constantly being pulled away on other responsibilities. I will get everything sorted as soon as possible!

---

Just had a chance to look at this a bit further. The reason why there are 2 queries for each URL is because the first query is just finding out the filesize. If we can't get that information then we don't proceed any further. If we do get that information then we proceed to download the page.
For Syringe, this works fine - we only lose the executable because I don't handle the output from the decompression properly (which will be fixed as soon as I can upload the new version).

Looking at the Ares RSS feed, we are trying to get the filesize using the following code:

Code:

Call thisInet.Execute(, "GET", , "Range: bytes=0-" & vbCrLf)
[wait a bit]
sBuffer = thisInet.GetHeader("Content-Length")
If Len(sBuffer) <> 0 Then GetRemoteFileSize = Val(sBuffer)

This returns a value for the Syringe url but for the Ares RSS feed I get nothing back, so sBuffer is an empty string. This used to work okay so Im not sure what is wrong on the Launch Base side.
I could try skipping this step and see if LB can successfully download the page...

[Renegade]

That FTP thing should be fixed.

The 206 description says "The server is serving only part of the resource due to a range header sent by the client.
...maybe LB isn't sending the necessary range header to the server when getting Ares, thus not getting a range'd response back?

[Marshall]

Version 0.99.228 is up. I'm not sure why the Ares check would fail when the Syringe one doesn't because they both use the same code to get the file size. And it was definitely working before.
Still looking into it...

EDIT:
As far as I can tell the problem is the server not returning the header information (specifically "Content-Length").
I found an identical case that said the problem was the ISP blocking the request to the particular file...

It might be possible to download the file without access to the headers but it might mess up my method for detecting timeouts.


EDIT 2:
It looks like this is still a problem. For some reason the server won't give Launch Base the content length of the Ares RSS feed. I will look into rewriting the Ares update check to ignore this and try to download the feed anyway.

EDIT 3:
Work around implemented in version 0.99.229