Moving songs using either 'move' or 'moveid' to position -1 (after the
current song) would fail for a song which is just before the current
song.
This patch corrects the check to see if the current song is in the range
to be moved. Since the range is from `start` up to `end` (exclusive) the
check was incorrect, but is now fixed.
The implementation of cancel() did not work well: you cannot use
alSourceUnqueueBuffers() to unqueue queued buffers, and our function
openal_unqueue_buffers() left the OpenAL library in a rather undefined
state; nothing was supposed to be queued, but the "filled" variable
was not reset.
The local variable was already divided by 1000, and the return value
was being divided by 1000 again - doh! This caused delays in the
httpd output plugin that were too small by three orders of magnitude,
and the buffer was filled too quickly.
WinAPI explicitly declares filesystem encoding.
It can be determined by GetACP().
Use that instead of Glib routine that always "detects" UTF-8 on Win32,
which is incorrect for MPD case.
Ensure that WINVER is defined early enough, so other system headers
won't fall back to their default value. Specifically, this solves a
build failure (-Werror) with mingw-w64 ("WINVER redefined").
When we have an absolute path that's not inside the music directory,
allow loading it anyway, if we're in "secure" mode (i.e. the client is
connected via UNIX socket).
Right now, a playlist with absolute pathnames can only add songs that
are in the same the directory of the playlist or under it.
If uri is an absolute pathname and base_uri is set,
playlist_check_translate_song() will check that base_uri is a prefix
of uri, excluding every other song in the music directory outside
base_uri.
I think in this case base_uri should be completely ignored (and made
NULL) and uri should just be checked against music root directory.
Previously, the condition "defined(play_audio_format)" was used to see
if an output device has been opened, but if the device had failed on
startup, an assertion failure could occur. This patch adds a separate
flag.
The Naim Uniti does not appear to support icecast-style streaming of FLAC
music but does support the codec from a DLNA server. This change looks for
"transferMode.dlna.org: Streaming" in the HTTP request header and responds
with something the Uniti (and hopefully other DLNA clients) accepts.
The only difference in the DLNA streaming mode is the reponse header and
that icecast metadata is disabled. If a client request indicates both modes
are supported, the DLNA mode is preferred (as the Uniti says it supports
both but then rejects a FLAC ICY stream).
Note: This change may be specific to Naim equipment (the only device it was
tested on). E.g. the hardcoding of Content-Length which works but is not a
logically correct value. The change should be backwards-compatible, so
only those clients requesting a DLNA stream will see any difference.
When playing a CUE track, the player thread waited for the decoder to
become ready, and then sent a SEEK command to the beginning of the CUE
track. If that is near the start of the song file, and the track is
short enough, the decoder could have finished decoding already at that
point, and seeking fails.
This commit makes this initial seek more robust: instead of letting
the player thread deal with the difficult timings, let the decoder API
emulate a SEEK command, and return it to the decoder plugin, as soon
as the plugin finishes its initialization.
Add GMutex, GCond attributes which will be used by callers to
conditionally wait on the stream.
Remove the (now-useless) plugin method buffer(), wait on GCond
instead. Lock the input_stream before each method call. Do the same
with the playlist plugins.
