This completes the bug fix commit
2065e3290452377b2931f3129b230c8cc536cbc8; if we clear "queued" then we
must clear "queued_song" as well, or another variant of the assertion
fails.
In current Android SDK releases, Ant support was removed. Move the
necessary build steps from the former Ant build system to our Makefile,
and call the required build tools from the Android SDK (aapt and dx),
Java SDK (javac) and Info-ZIP (zip) directly.
[mk: copied from Felix's commit
e52b906dba971a1173f9e8f83d32b52ee9f89af3 in the XCSoar project)
Fixes deadlock because FileInputStream::Read() unlocks the mutex
(which was not locked) and then locks it, keeping it locked. This can
result in a deadlock. This happens because the archive and the file
mutex are different.
If a directory is a mount point, omit the "directory: " as well.
This bug is years old, but has become more visible now that mount
points are persistent in the state file.
If `SimpleDatabase::Visit` is called on a database that contains a mounted directry the URIs of the elements passed to the callbacks are not prefixed by the mountpoint path. This leads to lsinfo and add not working because they use the wrong URI. This pull request is using the `WalkMount` helper function to create prefixed versions of `VisitDirectory`, `VisitSong` and `VisitPlaylist` to add the correct prefix to the parameters of the callback functions.
[mk: the following text was copied from
https://github.com/MusicPlayerDaemon/MPD/pull/167]
For certain format (hi-res files) and normal buffer size hardware, The
hardware may at once consume most of the buffers. However, in Delay()
function, MPD is supposed to wait for 25 ms after the next try. it
will create a hiccup. The negative impact is much major than
increasing the latency.
I understand larger buffers come at a price. That's why in my earlier
commit last year I significantly reduced it. However, the buffer size
in CoreAudio is set according to the hardware, which is super small
latency. For instance, the system audio of 2015 generation of macbook
pro has maximum buffer size of 4096 samples, which is just 0.09s for
44.1k framerate, or 0.04s for 96k frames --- . compare to the 0.5 sec
latency alsa plugin has, even if we quadruple it, it's still super
tiny.
libupnp 1.6.24 added a few badly designed macros which break the MPD
build:
8177a4195a/
To work around this, we disable our emulation functions (from
714011c81e) on this libupnp version.
Closes#163
Without the flush, ReadPage() may not return any data, or not all
data. This may result in incomplete ddata the new "header" page,
corrupting streams with some encoders such as Vorbis.
Fixes#145
Don't require a quality or bitrate setting. If nothing is set, don't
fail startup - just go with a good default. A quality setting of 3 is
what "oggenc" defaults to as well.
InputStream::Read() and InputStream::Seek() are called with the mutex
locked. That means the implementation must not block, or unlock the
mutex before calling into blocking code.
Previously, a slow CD drive could stall the whole MPD process,
including the main thread, due to this problem.
Closes#149
Turns out that using CP_ACP is a lousy idea, because only very few
Unicode characters can be represented by it. Instead, switch to UTF-8
(which every sane person on other operating system already uses).
Closes#102
Our previous use of Queue::SwapOrders() could cause surprising
results:
- sometimes, the old "current" song would be played again (if the
newly selected song had not been played already)
- sometimes, the old "current" song would not be played again (if the
newly selected song had already been played)
This is inconsistent, because it should not depend on whether the
newly selected song had already been played.
So instead of Queue::SwapOrders() we now use Queue::MoveOrderAfter()
and Queue::MoveOrderBefore(), which is more expensive, but also more
consistent. It attempts to retain as much from the previous order
list as possible, and only moves the newly selected song around.
If an early exception gets caught (e.g. from
AllocatedPath::FromUTF8Throw()) before
DecoderControl::CommandFinishedLocked() is called, the decoder thread
would go in an endless loop, because DecoderCommand::START is still
set.
Closes#118
Our IcuCaseFold() fallback using strxfrm() is not actually case
insensitive. This commit fixes the problem by switching to
strcasecmp(). That function is not guaranteed to support UTF-8, but
it's the best we can do in this sparse situation.
Closes#111
Max Kellermann