Some metadata were filtered out from the reply by directly checking
for their hash, including the hash value in the code. Remove the magic
values and compare dfm->field against the relevant dmap_* field as for
other special cases.
Update field types, add new fields (commented out). This fixes a number
of mis-assigned types. Update generated from the result of a /content-codes
request.
Introduce struct dmap_field holding the field tag, description and
DMAP type and use it in struct dmap_field_map to replace the tag,
desc and type fields.
This enables semi-automated updates of the DMAP fields information
from the output of a /content-codes request.
Most of the unsigned DMAP types were missing and assignments were incorrect
between signed and unsigned types. Fix all of this, and add (preliminary)
support for the new types.
This code in daap_reply_songlist_generic() is redundant with code
in (new) dmap_add_field() and can be removed, with a tweak: we must
ensure the val integer is always 0 if not used to override a value in
the transcoding case.
Try to be a bit more strict about integer types, use off_t or int64_t for
file size and file offsets.
Replace safe_ato*() by safe_atoi32() and safe_atoi64(), fix integer types
at call sites to match.
DAAP queries from Remote won't need HTTP authentication as they all
require a valid session-id; Remote can only obtain a valid session-id
if its pairing-guid is known to us (it did pair successfully with us).
iPhone remote will later want to query by album. Instead of doing a
fulltext query, it uses a 64-bit hash of the album + album_artist. It
is not necessary to use the same hash algorithm that iTunes uses. The
important thing is that we can later respond to a query=('daap.songalbumid:xxx')
with this value.
iPhone Remote uses the following requests to get cover art for
songs and albums:
/databases/#/items/#/extra_data/artwork
/databases/#/groups/#/extra_data/artwork
For now, we will return the valid and correct response that we
have "No content". In the future, the real artwork could be
extracted and returned here.
Clients like Front Row expect video/<type> for video streaming, whereas iTunes
likes application/x-dmap-tagged when streaming audio.
Based on a patch by Ace Jones <ace.jones1@yahoo.com>.
iTunes 9 sends requests with a Request-URI like
daap://10.1.1.20:3689/server-info
The DAAP server expected the Request-URI to be just /server-info, and so
couldn't match the request to any handler.
In addition, evhttp would declare this request a proxy request which also
broke keep-alive handling resulting in the server closing the connection
after the reply. iTunes doesn't like that.
iTunes and Roku devices do not encode + as %2B in the query string and
do not encode space as + either in the query string (though at least the
Roku encode space as %20 everywhere). This needs to be worked around or
browse queries fail to parse because + was decoded as space when the query
really needs a + character.
Julien BLACHE
Ace Jones