This is probably unsafe, and doesn't protect against symlink loops,
but we will eventually add this when we bring update*.c and inotify*.c
closer together.
This shouldn't really happen, but insane users might delete/rename the
music directory while MPD runs. What was even more insane was that
MPD crashed due to this. This is a workaround - there is currently
nothing useful we can do in this case; except maybe poll for the music
directory to reappear, but that's too much trouble for a user error.
I took these tag names from a MusePack sample file I got from a user.
These are not documented in the APE specification:
http://wiki.hydrogenaudio.org/index.php?title=APE_key
People seem to be using undocumented extensions to the specification
anyway, and the best we can do is attempt to support them.
Reduce the overhead. Most buffers used by MPD are around 2 to 4 kB.
8 kB seems large enough to keep heap fragmentation low.
Additionally, this patch fixes an off-by-one error in the alignment
formula.
On mingw32, snprintf() expects a 64 bit integer instead of a "long
int" for "%li" - this is not consistent with our expectation, so we're
using plain sprintf().
For some unknown reason, read() blocks on WIN32, even though it was
invoked inside the G_IO_IN callback. By switching to GIOChannel
functions, this problem is solved, and it works on both Linux and
Windows.
On WIN32, use g_io_channel_win32_new_fd() instead of
g_io_channel_unix_new(). There doesn't seem to be a practical
difference, but it seems more correct.
In mingw32, int16_t is not defined by sys/types.h, but it is by stdint.h,
and it is in the int16_t man page as being defined in stdint.h. Thanks to
mithi for help debugging.
Don't add it to the filter chain, because we need to apply replay gain
before cross-fading with the next song. Add a second replay_gain
filter which is used for the song being faded in (chunk->other).
This is useful at the maximum depth level, to update newly created
directories. It is however questionable if the hard-coded 5 seconds
delay is enough to create new directory trees with all of their files,
but we might make that delay configurable in the future.
Without libid3tag, we were trying to skip the ID3 frame (since
0.15.2). Its length however was not calculated at all, we were just
dropping everything from the current input buffer. This lead to the
first few seconds of the file being skipped. This patch attempts to
calculate the ID3v2 frame size with the formula from:
http://www.id3.org/id3v2.4.0-structure 3.1 and 6.2
