- 10 Jun, 2020 1 commit
-
-
Max Kellermann authored
When the client wants to seek, but the decoder has already finished decoding the current song, the player restarts the decoder with an initial seek at the new position. When this initial seek fails, MPD pretends nothing has happened and plays this song from the start. With this new flag, a restarted decoder marks the initial seek as "essential" and fails the decoder if that seek fails. Closes https://github.com/MusicPlayerDaemon/MPD/issues/895
-
- 30 Apr, 2020 1 commit
-
-
Max Kellermann authored
This reverts commit a5273d69. It was wrong and broke the MixRamp unit test. Closes https://github.com/MusicPlayerDaemon/MPD/issues/844
-
- 22 Apr, 2020 1 commit
-
-
Rosen Penev authored
Switching == to >= should be safe here since the next if is the opposite. Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
- 14 Apr, 2020 1 commit
-
-
Max Kellermann authored
Without this, the Pause() call would drop the ring buffers and would skip a considerable portion of the end of the song. Closes https://github.com/MusicPlayerDaemon/MPD/issues/824
-
- 26 Mar, 2020 1 commit
-
-
Rosen Penev authored
This is the case with uClibc-ng currently. Signed-off-by:
Rosen Penev <rosenp@gmail.com> (cherry picked from commit 769cd0ee9f0cf8ceb026aa751b5d4a390bb5dbdc) (changed define to match master)
-
- 16 Mar, 2020 2 commits
-
-
Rosen Penev authored
Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
Rosen Penev authored
This is the case with uClibc-ng currently. Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
- 13 Mar, 2020 1 commit
-
-
Rosen Penev authored
The former is deprecated by C++14. The standard says they are the same: The header defines all types and macros the same as the C standard library header<stdint.h>. Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
- 12 Mar, 2020 2 commits
-
-
Rosen Penev authored
The former was deprecated with C++14. According to the C++11 and C++17 standards, both files are identical. Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
Rosen Penev authored
Introduced in C++17. It replaces gcc's warn_unused_result. Found with modernize-use-nodiscard. Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
- 02 Feb, 2020 1 commit
-
-
Rosen Penev authored
Found with modernize-use-bool-literals Signed-off-by:
Rosen Penev <rosenp@gmail.com>
-
- 18 Jan, 2020 2 commits
-
-
Max Kellermann authored
-
Max Kellermann authored
-
- 23 Dec, 2019 1 commit
-
-
Max Kellermann authored
Works around build failures with ccache which may feed processed code to GCC, which doesn't have the "fall through" code comments.
-
- 03 Aug, 2019 1 commit
-
-
Max Kellermann authored
The check IsSeekableCurrentSong() was added by commit 44b20024 in version 0.20.19, but it caused a regression: by doing the branch only if the current song is seekable, the player would restart the current song if it was not seekable, and later the initial seek would fail; but we already know it's not seekable, and so we should fail early.
-
- 17 Jun, 2019 1 commit
-
-
Max Kellermann authored
-
- 31 May, 2019 2 commits
-
-
Max Kellermann authored
-
Max Kellermann authored
This reverts commit ff3e2c05. The check was necessary, after all, because this is what checked whether the decoder had finished the current or the next song. > The "queued" flag can only possibly be set if the decoder is still > decoding the current song or if the decoder is stopped. That was wrong because ProcessCommand() sets `queued=true` and also starts the decoder (if it was idle). > This is also what the following assert() checks. That was also wrong, because the assert() has two conditions. Closes https://github.com/MusicPlayerDaemon/MPD/issues/566
-
- 20 May, 2019 2 commits
-
-
Max Kellermann authored
If the decoder finishes decoding the current song between the two IsIdle() checks, MPD stops playback instead of starting the decoder for the next song. This is usually not visible problem, because the main thread restarts it via playlist::ResumePlayback(), but that way it, ignores "single" mode. As a workaround, this commit adds another "queued" check which re-enters the player loop and checks again whether to start the decoder. Closes https://github.com/MusicPlayerDaemon/MPD/issues/556
-
Max Kellermann authored
The "queued" flag can only possibly be set if the decoder is still decoding the current song or if the decoder is stopped. This is also what the following assert() checks. This check was not necessary.
-
- 26 Apr, 2019 2 commits
-
-
Max Kellermann authored
-
Max Kellermann authored
-
- 25 Apr, 2019 1 commit
-
-
Max Kellermann authored
-
- 19 Nov, 2018 1 commit
-
-
Max Kellermann authored
Since we switched from autotools to Meson in commit 94592c14, we don't need to include `config.h` early to properly enable large file support. Meson passes the required macros on the compiler command line instead of defining them in `config.h`. This means we can include `config.h` at any time, whenever we want to check its macros, and there are no ordering constraints.
-
- 12 Nov, 2018 1 commit
-
-
Max Kellermann authored
-
- 06 Nov, 2018 1 commit
-
-
Max Kellermann authored
This fixes a valgrind warning because `buffer_before_play` initialization needs to know the audio format from the decoder.
-
- 31 Oct, 2018 1 commit
-
-
Max Kellermann authored
-
- 29 Oct, 2018 1 commit
-
-
Max Kellermann authored
This emits the event even if PlayerControl::Play() is used to replay the current song, which emits the missing "player" idle event. Closes #381
-
- 23 Sep, 2018 9 commits
-
-
Max Kellermann authored
Keep MPD's footprint small until playback is requested.
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
-
Max Kellermann authored
Previously, there was the setting `buffered_before_play` which specified a percentage of the audio buffer, defaulting to `10%`. That was working well enough for quite some time, until high-quality audio formats became common. At 44.1 kHz, 16 bit stereo, MPD collected 2.3 seconds worth of data in the buffer before starting playback. With the same default settings and 192 kHz, 24 bit stereo, that was only 0.27 seconds. Making this depend on the byte size only leads to high latency at low quality, and too little data at high quality. The natural choice would be to use a duration instead of a byte size, which should give the same good experience with all audio formats. Since the `buffered_before_play` configuration setting was not understood well by users and caused more harm than good, this commit deprecates it. It has now no effect.
-
Max Kellermann authored
-
Max Kellermann authored
Simplify the formula, and I guess this makes the formula more reliable. Imagine somebody configured `buffered_before_play` larger than 25%; then the decoder would be woken up all the time. This doesn't seem logical. On the other hand, it's easy to understand that the decoder should be woken up below 75% buffer fill.
-
- 22 Sep, 2018 3 commits
-
-
Max Kellermann authored
Calculate the value only once.
-
Max Kellermann authored
-
Max Kellermann authored
-