2
Workaround For 3.7Gb Download!
Started by CapnKirk13, Jan 09 2014 06:55 PM
31 replies to this topic
#21
Posted 11 January 2014 - 02:46 PM
I have the patch 3.7gb bug too. I am using the google dns server as a workaround. If I switch back to default dns server it does the patch, as long as I use the google 8.8.8.8 and 8.8.4.4 then it works fine. I will keep checking each day to see if fixed.
#22
Posted 11 January 2014 - 03:16 PM
Just got the error as well, came here to see if it had been reported yet, then tried relogging normally after reading this thread and it let me in without incident.
#23
Posted 12 January 2014 - 03:05 PM
Just want to report that the issue is ongoing as it happened again today when I attempted to login at 3:05 PST. I closed the client and immediately relaunched it and was not prompted to patch but instead was allowed to start as usual. I have made no modifications to the default way MWO launches.
#24
Posted 13 January 2014 - 11:25 AM
So, I'm sad to see that there's still some persistence on this issue. It almost seems like a local caching issue now. Ardney, are you saying that now when you run the patcher for the first time it will try to impose the huge download, and then when you exit and restart it, the download is no longer imposed?
Also, I guess most of you are concerned about specifying your location in your profile info, but it would be immensely helpful if you could indicate (either here in this thread or in a private message to me) your general geographical location. I need to find the local CDN node that you're connecting to in order to determine whether or not it's cached the wrong version of certain files.
Also, I guess most of you are concerned about specifying your location in your profile info, but it would be immensely helpful if you could indicate (either here in this thread or in a private message to me) your general geographical location. I need to find the local CDN node that you're connecting to in order to determine whether or not it's cached the wrong version of certain files.
#25
Posted 13 January 2014 - 11:41 AM
My younger brother staying with me until his next deployment downloaded the patch and played a few rounds to check out what was new and then had this same thing happen. He can not even post under his account because PGI thinks he is a my alt account due to the same IP/Computer so he is banned from the forums, add that to this bandwith hog full of N.O.P.E.
Way to go PGI!
Way to go PGI!
#26
Posted 13 January 2014 - 11:50 AM
My location is the Central Valley in California.
#27
Posted 13 January 2014 - 12:51 PM
wintersborn, on 13 January 2014 - 11:41 AM, said:
My younger brother staying with me until his next deployment downloaded the patch and played a few rounds to check out what was new and then had this same thing happen. He can not even post under his account because PGI thinks he is a my alt account due to the same IP/Computer so he is banned from the forums, add that to this bandwith hog full of N.O.P.E.
Way to go PGI!
Way to go PGI!
Using the same computer or IP address should not "ban" any accounts. I have logged into my account from my brothers computer and had no problems. We also commonly run our two computers off the same network (IP) with no problems. The most that happens is that when you log in with a different account, the other account should get logged out.
The exception to this rule would be if they banned your IP address and saw an alternate account logging in from said banned IP address... but that doesn't sound like it's the issue.
PS: A mod is posting here, why don't you give him a private message about the issue, being nice about it and dropping the attitude? He might be able to either fix it, or tell you what is going on...
#28
Posted 13 January 2014 - 12:58 PM
wintersborn, on 13 January 2014 - 11:41 AM, said:
My younger brother staying with me until his next deployment downloaded the patch and played a few rounds to check out what was new and then had this same thing happen. He can not even post under his account because PGI thinks he is a my alt account due to the same IP/Computer so he is banned from the forums, add that to this bandwith hog full of N.O.P.E.
Way to go PGI!
Way to go PGI!
There's a guy here trying to help you and all you can do is be a {Richard Cameron} about it. Way to go, wintersborn!
I'll stay tuned for your next week's posting of "uneducated peasant rage"
Edited by cSand, 13 January 2014 - 01:03 PM.
#29
Posted 13 January 2014 - 05:19 PM
CDN engineer here!
Our CDN works on the principal of Geo-DNS resolution. This, assumes (sometimes incorrectly and yet so beneficial), that you're using DNS servers that are theoretically local to you.
West Coast, California AT&T would use a DNS server to serve a geographic area and, in turn, our CDN would respond to AT&T with an address that should be local to that area. Now, we suspect that a sever in the western United States did not get a command to refresh it's cache and was serving a version helper file that caused the patcher to constantly believe you have never patched before.
Changing to Google's DNS servers (8.8.8.8, 8.8.4.4) had the added benefit to give you CDN servers closer to Google's hosted location for it's DNS servers which had received the command to refresh; thus a happy patcher.
While switching to Google's DNS is a good short term solution; we could use your assistance to track these down. When this happens, please run nslookup patcher.mwomercs.com (tutorial) in a windows command prompt and paste the output to us. This can help us pin-point the bad evil server.
Our CDN works on the principal of Geo-DNS resolution. This, assumes (sometimes incorrectly and yet so beneficial), that you're using DNS servers that are theoretically local to you.
West Coast, California AT&T would use a DNS server to serve a geographic area and, in turn, our CDN would respond to AT&T with an address that should be local to that area. Now, we suspect that a sever in the western United States did not get a command to refresh it's cache and was serving a version helper file that caused the patcher to constantly believe you have never patched before.
Changing to Google's DNS servers (8.8.8.8, 8.8.4.4) had the added benefit to give you CDN servers closer to Google's hosted location for it's DNS servers which had received the command to refresh; thus a happy patcher.
While switching to Google's DNS is a good short term solution; we could use your assistance to track these down. When this happens, please run nslookup patcher.mwomercs.com (tutorial) in a windows command prompt and paste the output to us. This can help us pin-point the bad evil server.
#30
Posted 13 January 2014 - 06:20 PM
As of 5 minutes ago ( the last time I checked ) its working correctly. In case you still want the info...
Non-authoritative answer:
Name: user-att-76-246-40-0.a1982.d.akamai.net
Addresses: 23.72.38.128
23.72.38.146
Aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net
a1982.d.akamai.net
Non-authoritative answer:
Name: user-att-76-246-40-0.a1982.d.akamai.net
Addresses: 23.72.38.128
23.72.38.146
Aliases: patcher.mwomercs.com
patcher.mwomercs.com.edgesuite.net
a1982.d.akamai.net
#31
Posted 13 January 2014 - 07:36 PM
If anyone's not sure how to change their DNS, fire me a PM I will help ye
#32
Posted 14 January 2014 - 10:54 AM
Located on the Oregon Coast, US, my ISP is Frontier.
Happy to report that, as of 1030 hours, I no longer need to use command prompt to dodge the crazy 3.7gb patch. Looks like whatever PGI's staff did worked for me. Thanks guys!
Happy to report that, as of 1030 hours, I no longer need to use command prompt to dodge the crazy 3.7gb patch. Looks like whatever PGI's staff did worked for me. Thanks guys!
4 user(s) are reading this topic
0 members, 4 guests, 0 anonymous users