Some APEs report their am value as something like `AirPort4,107` (Old
version) or `AirPort10,115` (new version). (There is some evidence in
the player.c code that some old APEs do not report an AM value at all,
but all three of mine do.
As far as I can tell, the following is true of APEs with AM values:
- am="AirPort4..." - Encrypted (so devtype should remove
`RAOP_DEV_APEX_80211N`)
- am="Airport10..." - Not encrypted (so devtype should be set to
`OTHER`)
So, I suggest the following change to line 28:
```
else if (strncmp(p, "AirPort4", strlen("AirPort4")) != 0)
```
There may be other flavors of APEs that may fail this test, but it's
the best I can suggest with the devices I have.
revision-number in their update request.
Details: Banshee (v1.6.1) and Amarok client players send an
update request but do not send the revision-number parameter.
iTunes version 10 (and perhaps earlier) does send this parameter.
See: https://github.com/jasonmc/forked-daapd/issues/78
Fix: function daap_reply_update() now warns when revision-number
is not submitted by the client, but does not reply with an error.
In that case the server assumes a revision-number which insures
an update is sent back to the client.
Testing:
I verified that the following clients were able to connect succesfully
and retrieve a library listing:
* iTunes 10.5.2
* iTunes 10.4.2
* iTunes 9.7.1
* Rhythmbox 0.12.8
* Banshee 1.6.1
I can't test with Amarok since I don't have this client.
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.
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.
This happens under database load with many concurrent threads doing updates;
queries failing with SQLITE_SCHEMA at step time need to retried from scratch
until they succeeded or hit a best-effort limit of 5 retries.
The byte-order marks are useless for UTF-8, but that doesn't mean we don't
find them in the wild. Get rid of them, they confuse the hell out of the
collation functions.
Reported by Kai Elwert.
Handling of the sort tags was left into httpd_daap.c where the code runs
after the song is added to the songlist - effectively adding the sort tags
to the *next* song, leading to incorrect sort tags on the current song.
artist_sort tends to be more and more widespread, so try to reuse artist_sort
if possible instead of deriving album_artist_sort from album_artist
unconditionally.