Q: None of my iDevices can read my iTunes library after an hour of availibility. When I first start iTunes I can read the library, but after about 30 minutes my iPad's and iPhones can no longer access the library. I see it in the shared list, but no access.

New firmware for Apple TV: http://www.macnn.com/articles/12/06/05/no.major.changes.spotted.so.far/

Do I dare hope?

Haha.  I'm sure they fixed it, just as we're understanding the problem!

I updated the code to take the number of CLOSE_WAIT connections into consideration as well as whether the port is accesible.  The default CLOSE_WAITs allowed is five or fewer, but its configurable (at the top of the script are some variables you can tweak, if you feel like it).  If you turn on debug, it outputs the connection counts and date every five seconds (or whatever you set check_delay to).

Same drill for updating your script.  Launch a terminal (command-space; type terminal; hit enter).  Then copy/paste below commands.

download/install new one:

curl http://djw.s3.amazonaws.com/homesharing-keepalive.rb > ~/Documents/homesharing-keepalive.rb && chmod +x ~/Documents/homesharing-keepalive.rb

launch:

~/Documents/homesharing-keepalive.rb

Contents of script:

#! /usr/bin/ruby

debug = false # set to anything but false to get debug output

check_delay = 5 # delay between checks

max_close_waits = 5 # max allowed number of HS connections in a CLOSE_WAIT state

require 'socket'

def is_port_open?(ip, port)

  begin

    hs = TCPSocket.new(ip, port)

  rescue Errno::ECONNREFUSED

    return false

  end

  hs.close

  return true

end

def restart_itunes

  puts "Home sharing is broken.  I am going to restart iTunes."

  `osascript -e 'tell application "iTunes" to quit'` # exit iTunes

  sleep 10 # give iTunes time to shut down

  `open -a iTunes` # start iTunes

  sleep 30 # to avoid getting into an iTunes restart loop

  puts "iTunes restarted"

end

loop do

  num_hs_conns = `netstat -n | grep 3689 | wc -l`.to_i # total HS conns

  num_hs_conns_cw = `netstat -n | grep 3689 | grep CLOSE_WAIT | wc -l`.to_i # CLOSE_WAIT HS conns

  puts "#{Time.now} :: Number of HS connections: #{num_hs_conns} (CLOSE_WAIT: #{num_hs_conns_cw})" if debug

  unless is_port_open?("127.0.0.1", 3689) && num_hs_conns_cw < max_close_waits

    puts "#{Time.now} :: Number of HS connections: #{num_hs_conns} (CLOSE_WAIT: #{num_hs_conns_cw})" unless debug

    restart_itunes

    puts "#{Time.now} :: Number of HS connections: #{num_hs_conns} (CLOSE_WAIT: #{num_hs_conns_cw})" unless debug

  end

  STDOUT.flush

  sleep check_delay

end

minor update:  if you are running debug, after you've had a restart triggred, it will print an additional line every 5 seconds that reports the number of restarts that occured and when the last one occured.

That's all for now.  I'm going to let this bad boy run over night.

example debug output:

Tue Jun 05 19:18:02 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 1 :: last restart: Tue Jun 05 19:17:32 -0400 2012

Home sharing is broken.  I am going to restart iTunes.

iTunes restarted

Tue Jun 05 19:18:28 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 2 :: last restart: Tue Jun 05 19:18:23 -0400 2012

Tue Jun 05 19:18:33 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 2 :: last restart: Tue Jun 05 19:18:23 -0400 2012

Tue Jun 05 19:18:38 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 2 :: last restart: Tue Jun 05 19:18:23 -0400 2012

Nice work:

So here is where I sit right now, which I'm finding very interesting. I just updated both Apple TV's about an hour ago, which requires a full restart. I also restarted itunes. At present there is 0 connections and it's holding steady. Rather than thinking this is the update I'll assume this is probably because we haven't connected via home sharing yet. So if that is true (which I'll test) the connection problem only pops up after you make the initial connection. Not sure why it would spawn connections after you connect if that is the case...

Or maybe they really did fix in on the Apple TV end .

I'll report back.

LOL, just kidding. Ignore that last post completely. I forgot to start itunes. Haha.

I've had no problems this morning, after updating both AppleTVs last night. I've been running aut0maticdan's script in debug mode, and it hasn't reported any CLOSE_WAITs for over 6 hours.

Fingers cross Apple's update solved it, although it wasn't in the patch notes. That'd be typical of Apple though, brush the bug under the carpet without ever admiting it existed!

Props to aut0maticdan for the fantastic script!

I hope you're right.

I'm in about the same boat without the update, but the problem is nothing, if not inconsistent.  What are your total number of HS connections?

I watched for a few hours before bed last night.  My total number of HS connections is 52 which up from about 25 before bed.  Its growing much slower than yesterday afternoon.  I have 0 in the CLOSE_WAIT state.  I noticed that while watching HS, the number of connections does not grow at all.

EDIT:  Number of HS connections grew to 55 while writing that. 

Message was edited by: aut0maticdan

All is still ok here.

I took the log from your script and trimmed the output down to a CSV to look through it easily. Connections started at 1 at 07:00 this morning and have been stable at between 30 to 50 since programs have been playing on and off since 09:00. I've had a couple of spikes with the max at 96, but they all dropped down again. CLOSE_WAITS have been at 0 for the duration execpt for a single 3 at 09:00.

Currently at 43 HS connections, 0 CLOSE_WAITs whilst my son watches In The Night Garden on the Apple TV

Yep, I'm on 5.0.2 as released on 5th June.

So far so good for me. The connections have stayed down. Funny that no one knows what this update is for but us .  I feel like an apple insider.

Haha...  Good to hear, cendrizzi.  Thanks for running the debug and giving feedback!

so while I've been away this morning, I've had a restart due to CLOSE_WAITS > 5

Wed Jun 06 11:18:13 -0400 2012 :: Number of HS connections: 100 (CLOSE_WAIT: 0)

Wed Jun 06 11:18:18 -0400 2012 :: Number of HS connections: 101 (CLOSE_WAIT: 1)

Wed Jun 06 11:18:23 -0400 2012 :: Number of HS connections: 102 (CLOSE_WAIT: 2)

Wed Jun 06 11:18:28 -0400 2012 :: Number of HS connections: 103 (CLOSE_WAIT: 3)

Wed Jun 06 11:18:33 -0400 2012 :: Number of HS connections: 104 (CLOSE_WAIT: 4)

Wed Jun 06 11:18:38 -0400 2012 :: Number of HS connections: 105 (CLOSE_WAIT: 5)

Home sharing is broken.  I am going to restart iTunes.

iTunes restarted

Wed Jun 06 11:19:24 -0400 2012 :: Number of HS connections: 100 (CLOSE_WAIT: 0)

restarts: 1 :: last restart: Wed Jun 06 11:19:19 -0400 2012

Home sharing is broken.  I am going to restart iTunes.

iTunes restarted

Wed Jun 06 11:20:09 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 2 :: last restart: Wed Jun 06 11:20:04 -0400 2012

Wed Jun 06 11:20:14 -0400 2012 :: Number of HS connections: 0 (CLOSE_WAIT: 0)

restarts: 2 :: last restart: Wed Jun 06 11:20:04 -0400 2012

There were two quick restarts, so I guess the 30 seconds wasn't quite enough for my itunes to reboot and get HS going.  I may increase this a bit but doesn't seem to be a big deal.  It likely got hung up a bit shutting down (or crashed).

I find it interesting that it started creating CLOSE_WAITs right as it crossed the 100 connection mark.  This is my first time observing the phenomenon unfold with this much data, so there may or may not be something to it.  I am currently back up to 18 open connections (0 are CLOSE_WAIT).

Now that I've seen it occur, I am going to update my appletv when I get home and see how things go with that.  Even if that doesn't resolve the issue, I expect that this script running will keep me working until they do really fix it (WWDC itunes update anyone?).

aut0maticdan:

I haven't seen a single CLOSE_WAIT since the update. Just FYI.

Fingers crossed.  What gives me hope is that you said your number of connections was going up AND DOWN.  I don't think I've ever seen mine decrease.  That's a great sign that connections are getting managed!