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.
evbuffer_read() is really meant to read from sockets and not regular
files. It also looks like evbuffer_read() was causing issues with large
files, locking up a little below 2 GB for an unknown reason (couldn't
reproduce).
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.
Hinting the OS about our behaviour shouldn't make a big difference in
performance but it will help the OS manage its disk cache and can reduce
memory pressure on small systems.
