Commit d42c0f1dc5 added an OS X-specific
method of calling mpd_main_after_fork(), which uses Grand Central
Dispatch. Since this uses a block literal, it breaks compilation on
compilers which don't support the block extension, e.g. non-Apple
compilers. This affects users on older OS X releases with GCD (which
depend on older Clang releases, or Apple GCCs, which don't support the
C++11 features MPD needs); or which don't support GCD at all (10.5 and
lower).
This patch changes the #ifdef so that the non-GCD code is used
as it was on OS X before this patch if blocks aren't available, via
checking __BLOCKS__ macro.
The old formula calculates the output buffer size with "regular"
rounding (to the nearest integer), however sometimes, that is
insufficient and the last sample cannot be resampled. This causes
audible distortions. By changing the formula to consider the worst
case (always round up), this problem is eliminated.
While seeking, metadata must not be updated. ResponseBoundary() was
added in MPD 0.19.1, but I forgot to add the IsSeeking() check there.
This caused the "seekable" flag to reset.
On "list albumartist", songs that have no AlbumArtist tag will use the
Artist tag. However, if AlbumArtist is disabled via
"metadata_to_use", the TagBuilder::AddItem() call is ignored, and
PrintUniqueTag() attempts to print a nullptr string.
This commit fixes the problem by attempting the fallback only if
AlbumArtist is not disabled.
When uri_apply_base() was moved from db/upnp/Util.cpp to
util/UriUtil.cpp, the parameter order was changed, however without
swapping the parameters in the ContentDirectoryService constructor.
Many years ago, FAAD had a serious ABI bug: the NeAACDecInit()
prototype in its header declared the "samplerate" parameter to be
"unsigned long *", but internally, the function assumed it was
"uint32_t *" instead. On 32 bit machines, that was no difference, but
on 64 bit, this left one portion of the return value uninitialized;
and worse, on big-endian, the wrong word was filled. This bug had to
be worked around in MPD (commit 9c4e97a6).
A few months later, the bug was fixed in the FAAD CVS in commit 1.117
on file libfaad/decoder.c; the commit message was:
"Use public headers internally to prevent duplicate declarations"
The commit message was too brief at best; the problem was not
duplicate declarations, but a prototype mismatch. No mention of the
bug fix in the ChangeLog.
The MPD project never learned about this bug fix, and so MPD would
always pass a "uin32_t *" dressed up as a "unsigned long *". Nearly 6
years later, it's about time to fix this second ABI problem. Let's
kill the workaround!
Many years ago, FAAD had a serious ABI bug: the NeAACDecInit()
prototype in its header declared the "samplerate" parameter to be
"unsigned long *", but internally, the function assumed it was
"uint32_t *" instead. On 32 bit machines, that was no difference, but
on 64 bit, this left one portion of the return value uninitialized;
and worse, on big-endian, the wrong word was filled. This bug had to
be worked around in MPD (commit 9c4e97a6).
A few months later, the bug was fixed in the FAAD CVS in commit 1.117
on file libfaad/decoder.c; the commit message was:
"Use public headers internally to prevent duplicate declarations"
The commit message was too brief at best; the problem was not
duplicate declarations, but a prototype mismatch. No mention of the
bug fix in the ChangeLog.
The MPD project never learned about this bug fix, and so MPD would
always pass a "uin32_t *" dressed up as a "unsigned long *". Nearly 6
years later, it's about time to fix this second ABI problem. Let's
kill the workaround!
MPD handles all strings in UTF-8 internally. Those decoders which
read Latin-1 tags are supposed to implement the conversion, instead of
passing Latin-1 to TagBuilder::AddItem(). FixTagString() is simply
the wrong place to do that, and hard-coding Latin-1 is kind of
arbitrary.
The Release Track Id uniquely identifies a recording on a release - that
is, even if a recording appears twice on a release (meaning that the
combination of recording and release id are not enough to figure out
which one it is), the release track id will allow differentiating the two.
The tag names are taken from
https://musicbrainz.org/doc/MusicBrainz_Picard/Tags/Mapping
