Apple TV 3rd gen. DoS-bug stopping homesharing

After 24 hours with the new software release I am finding myself in the same end state, albeit via a slightly different route.

Whereas up until now the DoS end state was accompanied with scores of established connections to the DAAP port on the iTunes Home Sharing server (Windows or Mac), now the same DoS end state is accompanied with scores of established connections between the Apple TV and the iTunes Home Sharing server, though these connections are all on the high order ports (e.g. > 49000).

I will update my contact at Apple Care with this information. The next logical step is to RMA the Apple TV, but given you are observing the same issue, I doubt we are dealing with a manufacturing defect (unless of course the manufacturing defect aflicts all 3rd generation Apple TVs).

Stay tuned.

G.-A.

Mr. Webers, in my series of tests I came across an interesting nuance in the DoS bug we are investigating. I created an AppleScript that restarts iTunes automatically and log the number of connections established to the DAAP port, to get around the DoS. The script is scheduled to run three times a day (10AM, 4PM and 10PM).

Over time I noticed there were no connections to the DAAP port, while the AppleTV was still unable to connect to the HomeSharing server.

I updated the AppleScript to log the total number of connections to the AppleTV in addition to those on the DAAP port.

As it turns out I noticed the following behavior:

1) connections build up on the DAAP port until a point where the Apple TV can no longer view the contents of the Home Sharing library. (known behavior).

2) my script restarts iTunes.

3) now connections start building up until a point where the Apple TV can no longer view the contents of the Home Sharing library, but this time around the source and destination ports are in the high order, eg >49000 (new behavior).

4) iTunes is restarted at the next execution of the script.

5) the connection build up on the DAAP port resumes. (known behavior).

Are you seeing a similar behavior? I will gladly share my AppleScript if you'd like.

Here is an update for the record.

After numerous tests and reconfiguration of my set up with the clear goal of isolating this odd behavior, I have received an update from my AppleCare contact. Using his own words: "Right now your issue is under further investigation at the software level. Engineering has requested that you use either work around (Wi-Fi connection or running the restart script) in the mean time.

Keep up with your updates as when a fix is released, it will come in the form of an update.''

I will post an update if anything new on this front happens, but most likely you will find out at the same time I will.

Could you post the applescript or email it to me? I'd really like to try it on my mac.

Certainly, here it is the core of the AppleScript; I omitted the logging code that calls an other script to track the number of established sessions:

set HowManySessions to do shell script "netstat -n | grep <ATV IP address here> | wc -l"

set HowManySessionsDAAP to do shell script "netstat -n | grep .3689 | wc -l"

if HowManySessions > " 60" then

quitapplication "iTunes"

delay 5

tell application "iTunes"

activate

end tell

else

quitapplication "iTunes"

delay 5

tell application "iTunes"

activate

end tell

end if

Thanks for your script G.-A. Currently you have it restarting no matter what (the else clause). I updated it and added a check for iTunes running. There's probably a better way, but it works.

#!/usr/bin/osascript

set HowManySessionsDAAP to do shell script "netstat -n | grep .3689 | wc -l"

set HowManyiTunes to do shell script "ps -e | grep 'iTunes ' | egrep -v grep | wc -l"

if HowManySessionsDAAP > " 60" then

say "There is a problem with iTunes. I'm restarting it now."

quit application "iTunes"

delay 5

tell application "iTunes"

activate

end tell

end if

if HowManyiTunes = " 0" then

say "iTunes is not running. I'm starting it now."

delay 1

tell application "iTunes"

activate

end tell

end if

I added an entry to crontab (crontab -e) to fire every 30 minutes:

*/30 * * * * /Users/myname/iTunes-restart

This is to confirm that upgrading to Mountain Lion does not address the issue, as connections continue to build up and the familias symptoms return.

With the release of IOS 6 in a few weeks, my bet is that any fix will be rolled into an IOS 6-based version of the ATV software.

This morning I noticed a new version of ATV software based on IOS 6.0. After applying the software and restarting iTunes, you will notice the type of connections now uses IPv6. So far the number of connections remains stable at 4 established sessions. Looking good thus far.

Well folks, it is 12 hours later and I am glad to report no more recurrence of the symptoms we all are familiar with.

The version of ATV software is 5.1 (5201) running on OS Build 6.0 (10A406e).

ITunes is 10.7 (21) 64-bit

OS X 10.8.2

Thank you Mr. Weber for your clues about the problem, and all at Apple for nailing this one.