- Try to not return items which a client can't play
- Remove inotify subscription to IN_MODIFY and IN_CREATE
- Fix crash on unknown codec type in transcode.c
- Probably added some new bugs...
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.
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.
Auto-logout currently doesn't work as expected and breaks streaming etc once
the timeout occurs. Disable it until we can make it work as expected.
Maybe we'll need to upgrade the DAAP version.
Otherwise the closecb is called when the connection is closed/freed during
deinit, and this happens in the HTTP cleanup after the DAAP and DACP cleanups
have run, leading to spurious "struct update_request not found" messages.
It is now clear that multi-library support will not happen, so remove whatever
provisions were in the code for that.
It comes with a small change to the configuration file, too.
With this, DB schema version went to 9.
Store groups (only album groups supported at the moment) in the DB,
so their ids are persistent for the duration of the forked-daapd session.
Those ids are used to, among other things, retrieve artwork, so we must
provide ourselves some persistence here.
This brings us to schema version 8.
songalbumid is used a lot in queries from Remote; computing the hash for
each row is a major waste of time on big libraries and slow machines, so
let's store the hash in the table.
This brings us to schema version 7.
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.
