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.
Transcoded (decoded) files will now always come out in signed, little endian,
16bit, 44100 Hz, stereo format regardless of the format of the input file.
This in effect fixes transcoding (and playback on some devices) for files that
do not match this format.
There's probably a discussion to be had regarding handling of 48 kHz and 96 kHz
content, though, as downsampling to 44.1 kHz to have the client or final output
device upsample again is clearly not an optimal solution.
Add the setup_fail_codec label and jump to it if an error occurs once the
codec has been opened. In the raw input codepath, don't use this label until
the file is properly opened, as it also closes the fd and frees the raw
buffer.
This also fixes a file descriptor leak in the case where an error happened
after the file was opened in the raw input codepath.
ffmpeg doesn't convert ID3v2 tag names to generic metadata names, so
add the ID3v2 tag names to the table to pick them up.
This fixes scanning of MP3 files in various cases.
More in this post and its attachment:
<http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-September/076213.html>
Thanks to Raivo Hool for bringing up the issue and fix.
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.
Due to the two Murmur64 implementations for 64 and 32bit machines, the
hash is not compatible when moving the SQLite DB between 32/64 bit hosts.
So we'll recompute all the songalbumids at startup, just in case.
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.
lseek() returns an off_t and not an int, using an int to store and
test the return value means we'll error out when the position in the file
gets past INT_MAX.
The pairing hash actually uses standard MD5, so let's simplify the
code by using a standard MD5 implementation. Now that function is
readable and understandable by mere mortals.
Thanks to Jeff Sharkey for posting that simplified version.
eventfd has less overhead than a pipe, works as a counter and uses a
single fd. Use it on Linux if available (that should be pretty much
always given the glibc and kernel requirements).
512k might be a bit too much, as it can take time to read 512k from the
filesystem (and we're using a blocking read) or from the decoder. Going
down to 64k will make this more manageable and improve the response time
when streaming to multiple clients at the same time.
Julien BLACHE
Ace Jones