kupjones

Aaack, i grabbed the wrong one.  Yes, that works.   Dang-it -- I know this happened before but who knows.   Sorry for the wasted time.

Getting that pesky error again trying to download tankcorpses_tracks_beige_MCT_1.23.1.0b.7z.   It seems it is always "tankcorpses".  So, I went to manually download via the URL:

https://repo.nature.town/WoT/tankcorpses_tracks_beige_MCT_1.23.1.0b.7z

and I get the screenshot attached -- it is not a 500 or 404 error, it is an error that the connection was refused, so I am assuming this URL has changed and that https://repo.nature.town/WoT/ is no longer a valid website.

This URL, however, works 

http://files.rtor.nl/WoT/tankcorpses_tracks_beige_MCT_1.23.1.0b.7z

6 minutes ago, Aslain said:

Thank you for the reminder. There was indeed such a situation. As for me, the download is working correctly, and the file you've just mentioned isn't large either. I understand that, for instance, a 300MB file might get corrupted, but something that is only 1.8MB is very unusual.

Yes, which is why I believe it to be a corrupted cache on the server-side.   Those caches typically maintain a mapping of content + IP addresses, which eventually age out OR is cleared on a restart.   But it cannot be strictly the cache as the download via browser works fine -- so I suspect your sw download client has a timer that is not quite as forgiving as the browsers.

Either way, I expect it to clear itself at some point -- just wanted to let you know.

Maybe a note on the download page for the workaround -- I had to hunt for that URL (again) 😉

5 minutes ago, Aslain said:

What is the issue? 

Same as myself and others have reported in the past -- failure to download a particular .7z file.   In my case it is usually the "tank_corpses..." archive.    Going to the browser and entering http://repo.nature.town/WoT/tankcorpses_tanks_white_MCT_1.22.1.0.7z downloads it fine.   You and I last time fuzted around with the download support in the software you are using but I think ultimately it is a combination of the software client not being quite as robust as it should be and something on the serverside (likely with NGINX) that required a restart.    

Problem is back with this 07 release -- again, I suspect it to be a server-side issue that is fixed with a restart of the server and/or LB.   Just FYI

On 7/23/2023 at 9:21 AM, TTimoNN said:

@kupjones Thank you for your effort into debugging and giving us as much information as you can.

I cannot reproduce your problem after running downloads and extracts thousands of times on all DLC servers in the ring from various locations around the world.

None of the downloads timed out or ended up corrupt. But this is using purely curl/7z to verify, I cannot properly/automatically reproduce the installer because Windows/GUI stuff. I also cannot reproduce situations where the line has tons of packetloss/jitter, maybe I could simulate but that's out of the scope for a problem only 1 person seems to have.

 

Is this problem still happening for you?

The problem has corrected itself.  And I concur -- the issue *is not* presented when using curl/browser/wget/etc.    I suspect there was an issue with a caching host as the server site (likely part of NGINX) that only presented itself to the client plugin that is used in the Inno program.    I simply waited until a next gen of modpack, thinking that at some point the server team would refresh their systems.   And --- voila!   It works now.

Thanks for the reply!

Doubtful as any such issue with the intervening infrastructure would effect all downloads, not one specific file *unless* there is some additional caching going on somewhere for this specific file that we are not aware of.   The fact that another person is experiencing the same problem with exactly the same file points to a more systemic source -- but I have to admit it is bizarre.   

Last bit of evidence -- I can easily download the file via a direct URL **BUT** the HTTP download stalls for just a second, then successfully resumes.  This stall can only occur when the server does not respond within the timeframe that the client expects.   I suspect that the download plugin is not handling this stall correctly and errors.   So even if there is something going on with the network (like packet loss) standard HTTP server/client communications are quite robust and rarely error out so quickly.  Again, this points back to the download plugin not handling a download stall correctly.   Not that I can fix it, just the evidence pointing that way is overwhelming. 

same thing happened -- and its only that archive.  This really leads me to believe that it is something on the server side.  I have one more test to try (a diff PC) to see if it does the same thing.   I suppose I can also switch my ISP connection -- but then I would expect that to effect all downloads, and they are not.   

21 minutes ago, Aslain said:

inno download plugin

Having never used Inno before -- I took at the source code and there appears to be options in the Inno DP that allow setting various timeouts:

        
        { "ConnectTimeout",   [[Time-out value, in milliseconds, to use for Internet connection requests.     
                              Can be set to <tt>Infinite</tt> to disable this timer]],                                    "</tt>System default{note-3}<tt>" },
        { "SendTimeout",      "Time-out value, in milliseconds, to send a request",                                       "</tt>System default<tt>" },
        { "ReceiveTimeout",   "Time-out value, in milliseconds, to receive a response to a request",                      "</tt>System default<tt>" },

I'm not suggesting that you do anything to change your setup -- just that these options are there.  I am more inclined to believe that there is something going on within NGINX that requires a restart -- they cache frequently called for downloads and it is quite possible that the cache image is corrupted on one of the servers in the rotation or within NGINX itself.   But that is just supposition on my part.

BTW, Inno Setup is a neat looking package -- I'll have to dive into it some more 😉

Sorry -- I should have been clearer -- what are you using on the client side to handle making the download requests?   

On the server side -- most hosting sites use nginx to load balance amongst multiple download servers.   

Yes, it is quite esoteric -- very non-obvious.   What program or library are you using to manage the downloads from the server?

UPDATE:   VPN did not change the behavior (connected to Copenhagen just for grins).   Installer errored on the same archive -- tankcorpses_tanks_beige_MCT_1.21.1.0.7z.

When I download via browser/URL the download pauses, then goes into "resuming" mode.   The browser recovers from teh pause but I am guessing that whatever tool is being used to perform the download is not handling the pause well and calls it a timeout rather than going into resume mode.    

as another test I tried a browser download of Enh_Camo_pold77_9.17.1.7z which is 10x larger.  There was no pause/resume.  I tried on another package and no pause/resume.   For me, at least, it is this one package.

On 7/19/2023 at 9:39 AM, Aslain said:

With VPN? Try with VPN.

I can try VPN -- but I have to ask:  Is there something that VPN is expected to fix, since a VPN simply traverses the same connections (until it gets to the backbone) and just makes it look like the route has fewer hops -- or is that perhaps the suspected problem, too many hops?   

I'll give it a shot and see -- but I can tell you that a download of that same archive via URL is successful, it almost seems to indicate a timeout intolerance of the installer that made need to be tweaked.   But I'll try the VPN

LOL -- ok. I was just trying to be a good Aslain-citizen and not get one of those "Read my instructions and send me your logs" messages!   Whew, dodged that bullet.

Normally I would agree -- and it still could be but I would expect all downloads to be corrupted. not the same one over and over.   I did just manually download that "tanks" archive and place it in the DLC and re-ran the installer.  Everything worked.

I am going to try 2 other things -- I have 2 ISPs, Im going to try my secondary and I am also going to try a download on another PC just to see.   

I'm still curious as to why the installer reports the archive was extracted and copied successfully, when clearly the corrupt archive prevented it from doing so.    

... oh, and thanks for checking that end.

Looks to be a corrupted source mod file -- and its just this series

Followup -- why would the log show "successful" when the mod was not copied to the folder?   Maybe a better question -- how is "successful" determined in the code?   Just curious.   

See the 2 screenshots.  It appears to be specifically the "tanks" mod of this series -- I tried other colors and they seem to download as corrupt.   I can try a VPN -- but in this case I would expect all of the downloads to be corrupted and they are not.   Possibly the source files?

Thanks.  See my post in the pinned DL topic ..... could be related then.

Could be related to a post I made in the DL errors section as this only seems to happen with the tankcorpses mod.

The log file says these 2 were extracted OK

2023-07-19 07:34:39.267   [UpdateProgressGauge] Extracting: tankcorpses_tanks_beige_MCT_1.21.1.0.7z -- Result: OK
2023-07-19 07:34:39.419   [UpdateProgressGauge] Extracting: tankcorpses_tracks_beige_MCT_1.21.1.0.7z -- Result: OK

yet in the mods dir, only the tracks are there.   I checked the DLC, the tanks archive is in there and appears to be ok, but it was not copied contrary to what the log says.  BTW, this is the same archive (tanks) that I am seeing a download error on -- and I have a hard time believing it is simply a coincidence.   TBH, if there is a download error then I have no idea how the archive actually made it into the DLC.

_Aslains_Installer.log

Ran into a DL issue with latest 1.21.1 -- but only with the tankcorpses archive.   The DL times-out and throws an error.   When I go to the URL directly as in:

http://repo.nature.town/WoT/tankcorpses_tanks_grey_MCT_1.21.1.0.7z

the DL occurs BUT -- it is momentarily interrupted then resumes.   All other archives download fine.   Archive integrity appears to be ok

There is another error on install but I will post that separately with the log file -- could be related to this.

there are other topics in this forum that cover this issue --- its XVM themselves.   

try resetting the token on the AXVM webpage at the bottom of settings, eg.,

1 minute ago, Quaksen said:

Its on XVMs side, so nothing that can be fixed by you.

There have been instances where resetting the token resolved the issue -- but I too feel that it is on the XVM side, that resetting may only be a temporary fix

Could be -- we'll keep this in the back of our minds as a potential fix.

Thx!

Re-run the installer -- uncheck what you dont want, check what new ones you do.

Well -- apparently it was a bug on the XVM side and we all just reset the token right when they fixed it and just thought we fixed it.   But, its fixed