This issue occurs when playing HLS streaming delivered
from a server that does not support partial requests.
The issue is reproduced as follows(using Ubuntu 20.04 PC):
1. Prepare HLS example content.
$ mkdir test
$ ffmpeg -i example.flac -vn -c:a aac -b:a 128000 -f hls -hls_list_size 0 test/output.m3u8
(ffmpeg 4.2.4 is used)
2. Prepare web server without partial requests support.
(Docker version 20.10.12 and NGINX official Docker image is used)
$ docker run --name tmp-nginx-container -d nginx
$ docker cp tmp-nginx-container:/etc/nginx/conf.d/default.conf .
$ docker rm -f tmp-nginx-container
Edit default.conf and add "max_ranges 0;" to "location / {...}".
This disables partial requests support,
removes 'Accept-Ranges: bytes' header from the server response.
Then, run the server:
$ docker run --name test-nginx -v $PWD/test:/usr/share/nginx/html:ro -v $PWD/default.conf:/etc/nginx/conf.d/default.conf -d -p 8080:80 nginx
3. Setup MPD to Play the next URL.
http://address-of-the-server:8080/output.m3u8
Seeking this stream results in "exception: Not seekable".
Even if the "wave_encoder" option is disabled (and no other encoder
plugins are enabled), forcefully enable the Wave encoder (if Snapcast
is enabled).
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1500
This script setup a dummy android native app folder and call ndk-gdb from it.
It needs a modification in ANDROID_NDK since ndk-gdb may attach to the wrong
pid, cf. comments in the script.
Previous versions of MPD would call SetVolume on enabled outputs before
they are ready, causing all of MPD to crash. Checking the really_enabled
flag prevents this, though it also prevents setting volume before the
player starts.
Before (with the PipeWire output):
[i] ~$ mpc clear
volume: 81% repeat: off random: off single: off consume: off
[i] ~$ systemctl --user restart mpd.service
[i] ~$ mpc volume 100
MPD error: Connection closed by the server
[i] ~ 1 $
After:
[i] ~$ # mpd is freshly started w/o anything in the queue
[i] ~$ mpc
volume:100% repeat: off random: off single: off consume: off
[i] ~$ mpc volume 80
MPD error: problems setting volume
[i] ~ 1 $ mpc
volume:100% repeat: off random: off single: off consume: off
[i] ~$
Previous versions of MPD would, on parameter change, set the PipeWire
volume before clearing the restore_volume flag, causing the call to
short circuit and do nothing. Instead, clear the flag before the call.
Move audio output state check ahead of mixer check and force volume
applying even for disabled software mixed outputs.
This fixes incorrect software mixer volume that used to occur when
volume was changed while output being disabled.
This is easily reproduced with following sequence of commands on
multi-output software mixed MPD setup.
mpc volume 38; mpc disable 3; mpc volume 88; mpc enable 3
On current MPD, following commands would result in output 3 playing at
volume 38, while all other enabled outputs would play at volume
88. Moreover, global volume would display average of outputs real
volumes. In my case, it's 75.
After applying this patch, following commands would produce expected
behavior. All outputs play at expected (88) volume. And volume is
correctly displayed as 88.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1423
Signed-off-by: Vitaly Ostrosablin tmp6154@yandex.ru
Signed-off-by: Vitaly Ostrosablin <tmp6154@yandex.ru>
In libFLAC 0.3.4 (commit c9530118a4), the "dllimport" check has been
changed from "_MSC_VER" to "_WIN32", and now the MPD build is affected
by it.
Defining FLAC__NO_DLL disables the use of "dllimport", which allows
linking properly to the static libFLAC build.
Wasapi output plugin won't start playing after being paused
The cause is that the scope guard in the WASAPI work thread
(WasapiOutputPlugin.cxx, function WasapiOutputThread::Work(), in the
while (true) loop) is set up too 'late' in the execution. There is one
condition ("if (data_in_frames >= buffer_size_in_frames)") when it is
hit, the loop will continue without executing the scope guard. This
scope guard is responsible for emptying the buffer again, and if the
buffer is not emptied, the above mentioned condition will stay true.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1451
ffmpeg from current git master no longer exposes
av_malloc() nor av_free() through other included
headers. directly include libavutil/mem.h to fix
compilation with (as-yet-unreleased) ffmpeg.