Thanks for all the input. If it works for other people on the same ISP (like Luke) then won't the ISP just say it's MC? Do you know of other threads/forums where people are having the same issue that I could point my ISP too?

That's why I mentioned "zones", of some sort, even in C.T. it's seems different between AH users.

I heard that a few MWEB users are also having problems, but I don't know if it's related to this service. MyBroadband may well have similar complaints.
You could send a PM to Geoff D in case he knows more, if he's around this weekend. I don't think he'll be watching this actual thread as he doesn't use CU.

Last year I was having Dstv buffering issues so after weeks of back and forth a MC technician got me to add this:

#197.80.253.142 cdn.dstv.com
197.80.203.175 v.dstv.com

to C:\Windows\System32\drivers\etc\hosts which worked better for a while but obviously 2 or 3 days ago MC or Afrihost changed something that left those 2 lines as a barrier. I opened up the doc, removed those 2 lines, saved and voila... it all works.

Last year I was having Dstv buffering issues so after weeks of back and forth a MC technician got me to add this:

#197.80.253.142 cdn.dstv.com
197.80.203.175 v.dstv.com

to C:\Windows\System32\drivers\etc\hosts which worked better for a while but obviously 2 or 3 days ago MC or Afrihost changed something that left those 2 lines as a barrier. I opened up the doc, removed those 2 lines, saved and voila... it all works.

Thanks! I will investigate this a bit further as to exactly what these suggested changes were trying to mask in MCs CDN setup and possibly also configuration issues on some ISP networks.

I cannot help but point out that in July 2015, we got to the exact same point where we could see it was an issue within MCs CDN setup!

So checking my log file I see that I reached this point in 2015.

RFC's 952 and 953 provide the background to why DNS is required these days.
When one is forced to resort to making changes on your local computers "Hosts" file it is because you are compensating for a DNS failure as a result of an incorrect setup somewhere in the network setup between you and the source you are trying to reach. The two changes that MC suggested OP make in his operating system were thus made to "force" the name resolution process. Now the dangers of doing this is IF the source company now change their setups or fix a problem, this resolution will now point to the wrong place resulting in what OP got. This first is a very cryptic comment line. The second change is the actual action line. The local Hosts file gets priority when names are resolved into IP addresses. It could also be related to a bug in the decoder sw. It could be as simple as a spelling error or an incorrect line in the code. And we know how many of those exist in MCs software! Tens of thousands!

The local hosts file should be blank of any active command lines, and is only used in very specific conditions by local network administrators. It should these days "never" be used in individual users' OS systems and devices. Hence why if you go and look at your PCs hosts file it should only contain comment lines and no active lines of code, except for maybe in extreme cases to sort out localhost name resolution.

So while MCs suggestion probably did fix the problem in the short term, it could never be anything more than a temp patch.

So, let is hope that finally MC has attended to their DNS issues which I reported to them the first time in May 2015!

Thanks! I will investigate this a bit further as to exactly what these suggested changes were trying to mask in MCs CDN setup and possibly also configuration issues on some ISP networks.

I cannot help but point out that in July 2015, we got to the exact same point where we could see it was an issue within MCs CDN setup!

So checking my log file I see that I reached this point in 2015.

RFC's 952 and 953 provide the background to why DNS is required these days.
When one is forced to resort to making changes on your local computers "Hosts" file it is because you are compensating for a DNS failure as a result of an incorrect setup somewhere in the network setup between you and the source you are trying to reach. The two changes that MC suggested OP make in his operating system were thus made to "force" the name resolution process. Now the dangers of doing this is IF the source company now change their setups or fix a problem, this resolution will now point to the wrong place resulting in what OP got. This first is a very cryptic comment line. The second change is the actual action line. The local Hosts file gets priority when names are resolved into IP addresses. It could also be related to a bug in the decoder sw. It could be as simple as a spelling error or an incorrect line in the code. And we know how many of those exist in MCs software! Tens of thousands!

The local hosts file should be blank of any active command lines, and is only used in very specific conditions by local network administrators. It should these days "never" be used in individual users' OS systems and devices. Hence why if you go and look at your PCs hosts file it should only contain comment lines and no active lines of code, except for maybe in extreme cases to sort out localhost name resolution.

So while MCs suggestion probably did fix the problem in the short term, it could never be anything more than a temp patch.

So, let is hope that finally MC has attended to their DNS issues which I reported to them the first time in May 2015!

Hi Geoff D

At the moment, our platforms and tech teams are still conducting some tests. Should the teams have any info to report, we'll post it.

The problem is that that of Geoff D's careful research and advice that was considered at the time did help improve things quite a bit, handled via MC Nic, but then someone set some things back to how it was...