Details:
iTunes v10.5 clients changed how they responded to DAAP
protocol, and started disconnecting when the forked-daapd server
sent an empty "refresh" reply ("mupd" protocol). This problem is
also coupled with session-timeout ("mstm" and "msal"); when these
server capabilities were enabled, iTunes 10.x clients did not poll
for updates and eventually disconnected.
I investigated DAAP network packets using Wireshark. I found that
a true iTunes server sends a set of server capabilities in a specific
order, and order matters to the client. When the correct order is used,
the client correctly polls for updates and does not disconnect.
This change:
1. Send server capabilities in different order (daap_reply_server_info).
2. Disables 5-minute update refresh.
3. Disables 30-minute inactivity time-out.
Testing:
This server version successfully stayed connected to the
following clients:
* iTunes 10.5.2
* iTunes 10.4.2
* iTunes 9.7.1
* Rhythmbox 0.12.8
The clients stayed connected for at least several hours,
sometimes days, with activity or no activity.
Craig Markwardt <craig.markwardt@gmail.com> found out that the 30-minute
timeout in iTunes was caused by the lack of reply to update requests.
We now send out replies every 5 minutes, avoiding the timeout and
disconnection.
Thanks to Craig for digging into this, producing code to demonstrate the fix
and trying out a few more ideas for update support beyond this fix.
SQLite has trouble optimizing the query when written with JOIN, but does
pretty well using the indexes when written without JOIN. Add an index for
the query, too.
An index on songalbumid helps for joins on songalbumid on the files table; a
covering index on disabled+media_kind+songalbumid helps in numerous queries
all over the place.
Modifications to db.c to enable the DAAP server to determine when
the media library has changed, and notify clients via an update.
Updates should show up to clients within 10 seconds.
Tested on iTunes 9.2.1
httpd_daap now responds to client "update" requests. Previously,
these requests were queued without response, and the client
closed the control session after 30 minutes of inactivity. This
modification pushes out an update response when a new database
revision becomes available, or 25 minutes, whichever comes sooner.
This change set does not monitor the database state, so dynamic
updates to a library listing do not occur. What you see at login
to the server is what you get.
Tested against iTunes 9.2.1; a connection stays up for hours,
regardless whether a song is being played or not.
In some complex ALSA setups, using PCM or Master is not the right thing
to do, so allow a custom mixer element name to be specified in the config
file for this use case.
Request and initial patch by Kurt Vanderlinden <kurt.vanderlinden@skynet.be>.
Pointed out by Raivo Hool; since we don't have a choice of performing or
not performing the metadata conversion, we will get "disc/totaldisc" for
ID3 files.
Craig Markwardt
Julien BLACHE
Peter Carmichael
Anthony Doko