While we are waiting for a fix (no, it isn't fixed yet), here are two analogies that might help people understand the behaviour they see.
First, picture that Netflix content is geographically distributed on many, many servers of three types of colors: red, green, and blue. Also, there are not equal percentages of each color. The ATV works fine when the content comes from a green or blue server, but buffers when it comes from a red server. When you want to watch a show, and it is a very popular one, it is likely cached on servers of all three colors. Netflix assigns you a server based on where the content is cached and your geographical location. If you are unlucky, you get assigned a red server, and your content buffers and is unwatchable. However, if you try again sometime later, you might be assigned a green or blue server, and it plays fine. If you are lucky the first time, it comes from a green or blue server, and there is no problem. If you watch an unpopular show, it might only be cached on a red server, in which case it is going to be impossible to watch. The randomness to this process under the covers means that it is very difficult to know if things are now fixed, and any tweaks we make like changing wireless channels might look like a fix, but are really just a luckier roll of the dice (but the luck streak will end).
Second, to understand why the ATV buffers, picture an auto assembly line in the old days. Manufacturers built up huge parts inventories (i.e. a buffer), and therefore could absorb hiccups in the supply chain, but they paid a big economic cost for this. Now, with just-in-time manufacturing, costs are reduced, but any hiccup in the supply chain stops production. This is what happened in the aftermath of the earthquake/tsunami in Japan. Well, Apple is using a very efficient adaptive bit rate scheme (probably the future for all), which gets just the right number of picture bits it needs to maintain picture quality, meaning it minimizes both the network bandwidth and buffer size it needs. But, this also means it can't absorb big hiccups to the bit supply. The "red servers" that I described above are giving quite a hiccup. The number of lost packets, timeouts, retransmissions, etc. lead to tens of packets a minute taking longer than 1.5 seconds to arrive, a lifetime in network time. When this happens, the ATV gives up, closes the connection, and then reopens a new one (but interestingly, usually back to the same red server). This combination of a trickle of packets, connection teardown, connection setup takes about 20-30 seconds, and we see this as "buffering", which is really a minsnomer because there really isn't much of a buffer. But, since the ATV goes back to the same red server, this "buffering" cycle goes on and on.
If you have read this far, you might just ask "Why doesn't Netflix just stop using the red servers with the ATV?", which is exactly what I proposed to Apple for the interm. Also, I am being careful here not to blame the red server vendor (yet), because it might turn out that there is something along the route to those servers, or at the ATV interface, that causes problems with the red servers, but isn't directly the red server vendor's "fault".
