iTunes 10.5.x: httpd connection failed

[attunicity]

I'd upgraded iTunes (on Windows 7/64bit) thru two iterations of v10.5 (most recently 10.5.1.42) and experienced an httpd error (iTunes <-> forked-daapd) after 4-5 minutes of playing. iTunes drops the connection to the forked-daapd library completely.

httpd: Connection failed; stopping streaming of file ID 826

I've regressed to iTunes v10.2.2.12 & all is playing again.

Superficially, it appears to manifest like the iTunes timeout issue previously fixed in v0.19

[zim2dive]

I am also seeing frequent "Connection failed" in the log.. I average less than 2 complete songs before losing the connection.

[zim2dive]

My fails were with iTunes 10.5.1, Win7x64.. I can confirm that rolling back to an older version (10.3 in my case) allowed me to play 20 songs in a row with no disconnect.

[billhamilton]

I'm also having problems on iTunes 10.5.1 OSX 64bit.

Once I start up forked-daapd on my Linux box and then try to connect in iTunes, it just sits there at "Connecting" and doesn't proceed any further.

In forked-daapd.log it looks like a /login request is received and then nothing is logged after that.

Has something maybe changed in iTunes 10.5?

I don't recall making any config changes.

[kekiefer]

@billhamilton, I believe your lack of connectivity issue is a different one. It sounds like you can't connect in the first place rather than dropping a connection. I had a similar problem to yours and solved it by setting "ipv6 = yes" in the configuration. Does this work for you?

[billhamilton]

Strangely enough I am running a dual-stacked network here.

I've tried putting that into the general section of the .conf as you suggest, but alas it hasn't resolved the issue.

I don't see the connection attempts in the debug log either - should I be seeing them?

[kekiefer]

Now that I'm thinking deeper about this, I do recall I had to sort some Avahi issues on Linux for this to work. Can you ping your Linux box by its avahi name?

When I looked at the traffic, it seemed that although iTunes successfully pulled down the playlist, it insisted on another MDNS (A) lookup during playback. This lookup would fail, and so it would never even attempt to connect. I'm not sure if this is indicative of a larger network configuration issue on my part.

To get around this, I set "publish-aaaa-on-ipv4=yes" and "publish-a-on-ipv6=yes" in the avahi-daemon.conf and things suddenly went smoothly. If this works for you, great! If not, you best bet may be time to dust off your copy of Wireshark ;)

I'll be glad to help you out offline if I can, I think this thread is sufficiently off-topic now! gmail, kekiefer

[billhamilton]

Tried both of those and still running into issues.

I've had a look in netstat and when I fire up iTunes and give it a try I can see that port 3689 goes to ESTABLISHED and then to FIN_WAIT2, so it's clearly trying something.

I'll have another poke around before I get out the packet tracers, but I can't understand why it was working before then suddenly stopped when I upgraded iTunes.

It's a busy week for me, but I might ping you a mail towards the weekend if I still have problems :)

[lpar]

I can't get it to work with iTunes 10.5.2 either.

[noyez]

I am seeing this same problem. I tried tracing through the code and enabled some extra debugging statements. I haven't found the source of the problem, but this output might be useful to someone with a trained eye. Note, some of it is my own debug statements. In the output you can see that it stops streaming file ID 1191 early, then restarts the process.

(Last several lines before forked-daapd restarts using itunes 10.5.2 on OS X 10.6.8) ... httpd: Read 65536 bytes; streaming file id 1191 event: evhttp_write_buffer: preparing to write buffer httpd: Read 65536 bytes; streaming file id 1191 event: evhttp_write_buffer: preparing to write buffer

httpd: Read 65536 bytes; streaming file id 1191 event: evhttp_write_buffer: preparing to write buffer

event: evhttp_add_header: key: Content-Encoding val: gzip

event: evhttp_add_header: key: Date val: Thu, 29 Dec 2011 19:24:59 GMT event: evhttp_add_header: key: Content-Length val: 44 httpd: ( evhttp_send ) ; event: evhttp_write_buffer: preparing to write buffer

event: evhttp_write: evbuffer_write httpd: ( in write ) n=-1, fd=32, what=4 httpd: ( connection_fail ) Connection = -1; httpd: ( in free ) Connection = -1; httpd: Connection failed; stopping streaming of file ID 1191 event: evhttp_read: got 0 on 27

event: evhttp_handle_request: req->uri=(null) event: evhttp_handle_request: bad request httpd: ( in handle_request ) bad request httpd: ( connection_fail ) Connection = -1; httpd: ( in free ) Connection = -1;

[CraigMarkwardt]

This issue is a duplicate of issue #19, having to do with a change in how iTunes 10.5 clients deal with inactivity. The patch posted in that thread https://github.com/jasonmc/forked-daapd/issues/19#issuecomment-3328436 Should resolve the issue. I also submitted the patch upstream.

[noyez]

@CBGoodBuddy -- thank you for commenting on this thread, i didn't find #19 in my search. And, thank you for your code. I did a fresh git clone and applied your patch, and i've been running fine.

[svdlinden]

This issue is not a duplicate of #19. The discussion in #19 has moved from the initial issue to this one. The solution to #19 is the root of this very issue. Indeed, forked-daapd does not implement database updates but uses that as a keep alive mechanism instead.

forked-daapd replies to update requests about 5 minutes after the request in the hope that the client requests the database again and subsequently resets the session expiration timer. But when forked-daapd replies to iTunes with the same revision number that iTunes already knew about, the latter immediately drops the connection.

With the patch above, sessions never expire. There might be better ways to deal with the issue.

[svdlinden]

Since there is, to my knowledge, no official bug tracker for forked-daapd, I have filed a bug against the Debian package which happens to be maintained by the author of forked-daapd: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683529

[CraigMarkwardt]

@svdlinden, the situation is a little more complicated than you describe. The behavior of the iTunes DAAP protocol implementation has changed over time. The problem is that we don't know exactly how the DAAP protocol works, so it needs to be reverse engineered.

The solution you describe - the 5 minute time out with database update response - was a stop-gap solution in forked-daapd v0.19 which allowed iTunes 10.5 to work. Unfortunately it does not work with iTunes 10.6. The patch I provided reverts the 5 minute timeout portion, which means that the HTTP response remains open, "paused," indefinitely, also known as "HTTP server push." As you say, it never expires. This is exactly what iTunes itself does. Unfortunately we can't do better than that.

What I discovered is that iTunes the client is very picky about how the initialization response is formatted. My patch also fixes the initialization response formatting. So the patch contains two things, the formatting fix and the reversion to HTTP server push. The allows forked-daapd to work with all versions of iTunes clients (10.4, 10.5, 10.6). It should resolve most of the time-out problems.

Unfortunately Julien Blache seems to have taken a break from development and left forked-daapd in limbo.