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.
