Netflix pausing/buffering issues

I grabbed an XBox that #1 child left behind when she went off to school, and did a quick hook up, - "with" - a *********** wireless hook up and it worked just fine. Just like the Wii does in the other room.

NOW, my question is (as an Apple person since 1983) how can I get my money back?

This ATV is nothing but a brick to me. I only got it for Netflix, so it is totally worthless.

Additionally, Apple needs to realize that people like me don't call Apple because all their other Apple devices work perfectly, and with that, think its something they have, or did that is the problem. So who will reimbursement me for the time I spent with Comcast getting a new router, then for the new wireless router I got, thinking mine sucked - but NO, it was the ATV Brick.

Disappointed and PO'ed.

SHARK

Last night I could not gain access to Netflix either on the ATV2 or on the ROKU.

Does anyone know if their servers were down?

Things look back to normal this evening in So. Cal.

I'm a NYC user who has a MacMini and a MacTV sitting next to my HD screen. The mini mac streams NetFlix just fine. The MacTV has been giving me the following message for days: "An Error Occurred Loading This Content. Try Again Later." Ever since I did the software update.

The same MacTV gets Apple for pay content with no problem. Both units are wireless.

This all happened after the software update. It's not because NetFlix is down. And I'm not talking about buffering issues. It won't play NetFlix period. And it used to work just fine.

Fact.

Thanks.

If you have not yet done so, try disconnecting the power from the ATV for about 30 seconds and then reapply it.

My speculation is that it has something to do with IPV6 and the security "fix" in Novemeber 22, 2010 that was put in place to address the ability for a server to track location of a connected device.

November 22, 2010 was the patch from 4.0 to 4.1. I would speculate the IPV6 "fix" broke netflix. Its just a speculation but too much of a coincidence to ignore. Of all the security release - this is the only one that talks about randomizing to location information for the device.

From Apple's Security Update Site. http://support.apple.com/kb/HT4565

Apple TV Available for: Apple TV 4.0 and 4.1

Impact: A server may be able to identify a device across connections

Description: The IPv6 address chosen by the device contains the device's MAC address when using stateless address autoconfiguration (SLAAC). An IPv6 enabled server contacted by the device can use the address to track the device across connections. This update implements the IPv6 extension described in RFC 3041 by adding a temporary random address used for outgoing connections.

You can read more about RFC 3401 here http://tools.ietf.org/html/rfc3041

Exerpt:

Some servers refuse to grant access to clients for which no DNS name

exists. That is, they perform a DNS PTR query to determine the DNS

name, and may then also perform an A query on the returned name to

verify that the returned DNS name maps back into the address being

used. Consequently, clients not properly registered in the DNS may not

http://tools.ietf.org/html/rfc3041#page-14be unable to access some services.

I don't think so. There is no sign of IPv6 addresses in the traces I have taken, and it will likely be many years before those addresses will be supported by the Internet infrastructure. Also, with this change, the randomizing of addresses is not meant to hide geographic location, but the hardware 48-bit MAC address (in other words, the specific device identity). This is a fix for the future.

IT'S FIXED!!!

Apple called today to say that the ATV2 development team reviewed my network traces, analysis, and recommendation and they are in agreement. They worked with Netflix, who turned off serving ATV2 Netflix content from the problem CDN (the one I refered to as the "red" CDN). After the call, I tried 10 Netflix movies, and ran each for 5 minutes, and none were served from the "red" CDN, and none buffered. I don't know if this is a permenant shutoff, or if it is temporary until the "red" CDN resolves the root cause of the network problem. I also never did figure out why some, but not all, ATV2 customers experienced this issue.

Now, I am sure that someone, somewhere, sometime will have a Netflix buffering issue and come to this thread to find this post saying that it is fixed, yet they still might see some buffering. Buffering (or more accurately pausing) can be caused by any significant delay on the network that is bad enough for the ATV2 to abort the connection (and we see this as pausing). The symptom of the problem that I am describing as fixed is one where the Netflix movie, typically about 30% of the time, typically pauses about 2-3 minutes into it, for about 20 seconds, then starts again for 30-60 seconds, then pauses, and this cycle keeps repeating. If you have been experiencing that issue consistently, it should now be resolved.

DUDE... If this fixes it, you are the freaking man. Thanks for your hard work.

Bradley Rubin wrote:

IT'S FIXED!!!

Apple called today to say that the ATV2 development team reviewed my network traces, analysis, and recommendation and they are in agreement. They worked with Netflix, who turned off serving ATV2 Netflix content from the problem CDN (the one I refered to as the "red" CDN). After the call, I tried 10 Netflix movies, and ran each for 5 minutes, and none were served from the "red" CDN, and none buffered. I don't know if this is a permenant shutoff, or if it is temporary until the "red" CDN resolves the root cause of the network problem. I also never did figure out why some, but not all, ATV2 customers experienced this issue.

Now, I am sure that someone, somewhere, sometime will have a Netflix buffering issue and come to this thread to find this post saying that it is fixed, yet they still might see some buffering. Buffering (or more accurately pausing) can be caused by any significant delay on the network that is bad enough for the ATV2 to abort the connection (and we see this as pausing). The symptom of the problem that I am describing as fixed is one where the Netflix movie, typically about 30% of the time, typically pauses about 2-3 minutes into it, for about 20 seconds, then starts again for 30-60 seconds, then pauses, and this cycle keeps repeating. If you have been experiencing that issue consistently, it should now be resolved.

Bradley: Many, many thanks for your skilled detective work. Bravo!

lol

Bradley, do you (or anyone else on this forum) ever have issues where the quality dips in a show or movie? Not just a buffering issue, but a noticeable drop in quality while watching? If so, does this new discovery fix this as well? Thanks for your hard work. This has been incredibly frustrating!

What is your actual internet speed? Netflix works on a variable bit-rate and if you have a slower network or if there is interference that will cause the quality to drop.

I have the fastest Time Warner internet speed they offer (up to 15mbps). Most of the time, it's well over 20 according to speedtest.net. I have a Roku as well & seldom have it rebuffer, as I'm assuming it doesn't work on the VBR method like the ATV2.

As far as I know Netflix uses the VBR method, it's not device-based. It makes me think that your issue is related to Bradley's findings. Hopefully it is resolved.

Both of you are right. The ATV will choose to degrade picture quality if throughput drops instead of buffering, and if throughput increases it will then improve the picture quality. The Roku will buffer ahead, so when a little loss of throughput occurs it will use up the buffered bits, up to a point, and then pause. The Roku picture quality is fixed for a movie at whatever rate it measures when the movie starts.

As far as the specific issue I was working on, the packets were lost on the way to the ATV, then retransmitted, and some of those were lost, so it was really a transmission mess, and there was a big time lag until the ATV received some of the packets, so at some point it had to give up. I am fairly bandwidth impared (under 2 Mbps), but it is interesting to think about what someone with your bandwidth would see. Since your bandwidth is only a piece of the pipleline, and since the main issue was the quality of the transmission and not the speed, I think that you would see a similar pausing behaviour and not get by with just a loss of picture quality. Reading this thread and others, this seems to be consistent with the experience of others... we all saw a pausing problem and it seemed independent of our ISP service bandwidth. So, I don't think that your quality drop issue will be resolved because of this fix, but I would be happy if I am wrong!