Jump to content

kupjones

Premium Member Tier II
  • Posts

    108
  • Joined

  • Last visited

  • Days Won

    3

kupjones last won the day on November 19 2022

kupjones had the most liked content!

Reputation

11 Good

About kupjones

Profile Information

  • Server
    NA

Recent Profile Visitors

2286 profile views
  1. Aaack, i grabbed the wrong one. Yes, that works. Dang-it -- I know this happened before but who knows. Sorry for the wasted time.
  2. 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
  3. 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) 😉
  4. 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.
  5. 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
  6. 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!
  7. 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.
  8. 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.
  9. 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 😉
  10. 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.
  11. Yes, it is quite esoteric -- very non-obvious. What program or library are you using to manage the downloads from the server?
  12. 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.
  13. 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
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.