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.
D'oh, we were reading 16 bit integers instead of 32 bit integers!
That caused silence when trying to play a 32 bit input file on a 24
bit sound card (e.g. USB sound chips with 24 bit packed samples).
Don't abort the configure script when avahi could not be
auto-detected. It previously did, because there was no custom "fail"
action for PKG_CHECK_MODULES.
The output thread could hang indefinitely after finishing CANCEL,
because it could have missed the signal while the output was not
unlocked in ao_command_finished().
This patch removes the wait() call after CANCEL, and adds the flag
"allow_play" instead. While this flag is set, playback is skipped.
With this flag, there will not be any excess wait() call after the
pipe has been cleared.
This patch fixes a bug that causes mpd to discontinue playback after
seeking, due to the race condition described above.
To demonstrate the new I/O thread. libsoup is well-integrated into
the GLib main loop, which made this plugin pretty easy to write.
As a side effect, we have to initialize the I/O thread in all debug
programs that use the input API.
This warning should only be logged when we really received something.
When the client disconnects, G_IO_IN is triggered, and the read
returns G_IO_STATUS_EOF.
In the "vorbis" plugin, this is a copy of the old flush() method,
while flush() gets a lot of code remove, it just sets the "flush" flag
and nothing else. It doesn't start a new stream now, which should fix
a few problems in some players.
Max Kellermann