I remember getting totally screwed over using nslookup where it kept giving me cached (stale) data. I have seen issues with the Windows 7 IP stack before. When I changed our internal DNS servers to forward to our ISP's servers for non-cached name resolution then we started seeing connects to the proper IP address at Microsoft in the log files and then WMC started getting real guide data. So it appeared to me to be two issues, one was that the hosts file was being ignored and the second was that Google was sending back stale data for that host name. It was consistently using stale data because the WMC machine was looking up the FQDN for the host (even though it was in the hosts file) and it was getting stale data from Google's DNS servers. but I viewed the actual traffic being routed to the Internet and it was not using the entries in the hosts file. I don't know - you'd think it would, and what you posted makes sense. I did not use wireshark to look at the WMC connections, but if ping is using the IP address from the hosts file, then why wouldn't WMC? This gibes with the number of people posting that when they implemented some voodoo (such as using a different connection) they all of a sudden started getting guide data. Thus, the conclusion that this is a DNS/routing issue. Using Google as the forwarders was giving us stale data. It was only when we used our ISP's DNS servers (a different network) for forwarding that the Windows 7 machine got fresh data. Firewall logs showed that outgoing requests to those servers were actually larger in bytes then the data coming back from MS (!!). All the dB files were coming back from MS as normal, it just happened very quickly because they contained, literally, no guide data. The Windows 7 machine was hitting Microsoft's servers that had not been updated since the changeover, thus, they contained no guide data because it had all expired So the entire process was working correctly, other then that the machine was still connecting to machines at Microsoft that contained no data. This was not the case with this Windows 7 machine.īut then, this is why the entire guide was being filled with No Data. I was pretty surprised when I found out that the hosts file was being ignored in Windows 7 and it was still hitting the wrong IP address.ĭNS resolution should stop dead at the hosts file - provided there is an entry for the host being resolved. I suggest installing wireshark, or similar, so that you can actually see with 100% certainty what IP address your machine is connecting to. I do find it interesting though that people are suggesting everything from sacrificing a chicken to dancing around a fire to get it to work This tells me that the underlying issue is a DNS issue. Google was sending back stale data for the guide FQDN. When we finally changed our own DNS servers to forward to our local ISP (as opposed to forwarding to Google) then, a nd only then, did the Windows 7 machine finally hit it the right servers and get the guide. This is not the first problem we've seen with the IP stack in Windows 7 and caching. Firewall logs clearly showed it completely ignored the hosts file. Did not matter whether the cache was flushed or the machine was re-started. but not the Windows 7 machine I was using. That's right, every O/S since TCP/IP was adopted looks at the hosts file for resolution first. What I found was that Windows 7 was explicitly ignoring the hosts file altogether. I posted about DNS issues a few pages back - interesting that no-one picked up on what was said. I have a list of area codes near me that show QTA info, still no guide. 65.55.186.113 ħ2.246.56.59 .comīy the way WMC does not complain, it goes through the rest of the setup.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |