> In file included from src/decoder/DecoderBuffer.cxx:21:0:
> src/decoder/DecoderBuffer.hxx:41:20: error: 'uint8_t' was not declared in this scope
> DynamicFifoBuffer<uint8_t> buffer;
> ^
> src/decoder/DecoderBuffer.hxx:41:27: error: template argument 1 is invalid
> DynamicFifoBuffer<uint8_t> buffer;
> ^
> src/decoder/DecoderBuffer.hxx: In member function 'void DecoderBuffer::Clear()':
> src/decoder/DecoderBuffer.hxx:61:10: error: request for member 'Clear' in '((DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'int'
> buffer.Clear();
> ^
> src/decoder/DecoderBuffer.hxx: In member function 'size_t DecoderBuffer::GetAvailable() const':
> src/decoder/DecoderBuffer.hxx:78:17: error: request for member 'GetAvailable' in '((const DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'const int'
> return buffer.GetAvailable();
> ^
> src/decoder/DecoderBuffer.hxx: In member function 'ConstBuffer<void> DecoderBuffer::Read() const':
> src/decoder/DecoderBuffer.hxx:87:19: error: request for member 'Read' in '((const DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'const int'
> auto r = buffer.Read();
> ^
> src/decoder/DecoderBuffer.hxx:88:27: error: could not convert '{<expression error>, <expression error>}' from '<brace-enclosed initializer list>' to 'ConstBuffer<void>'
> return { r.data, r.size };
> ^
> src/decoder/DecoderBuffer.hxx: In member function 'void DecoderBuffer::Consume(size_t)':
> src/decoder/DecoderBuffer.hxx:105:10: error: request for member 'Consume' in '((DecoderBuffer*)this)->DecoderBuffer::buffer', which is of non-class type 'int'
> buffer.Consume(nbytes);
> ^
This seems to be caused by a lacking include, fixed by the below patch.
I'm unsure what made this appear now, though, compiler and toolchain
libraries seem to be the same upstream versions that built 0.19.14-1
just fine in late March.
The Mutex and Cond constructors are only "constexpr" with glibc, and
this is what this #ifdef is about.
Backport of commit 459a812a
See http://bugs.musicpd.org/view.php?id=4511
When a reference counter is at its limit, don't allocate a new
TagPoolSlot - that would result in many TagPoolSlot instances with
ref==1. This in turn would make the linked list very very large,
which means quadratic runtime for many operations.
There were two ways this could fail:
1. division by zero when sysconf(_SC_PAGESIZE)==0
2. mmap() failure because the size parameter is not aligned to page
size
Neither ever happened: sysconf() never fails, and the only caller
passes a size that is already aligned. Phew.
Apparently all other C libraries are not compatible with "constexpr".
Those which are not will get a performance penalty, but at least they
work at all.
The initgroups() manpage says we need to check for _BSD_SOURCE. The
thing is that glibc deprecated this macro, and doesn't define it
anymore, effectively breaking all MPD supplementary groups.
The real fix is to check for initgroups() availability at configure
time, instead of relying on the deprecated _BSD_SOURCE macro.
Apply padding only to the fseek(), not to the chunk size. This fixes
bogus "failed to read riff chunk" messages when the last chunk has an
odd size.
See http://bugs.musicpd.org/view.php?id=4486
Allocate the buffer dynamically using av_malloc(), and free
AVIOContext.buffer in the destructor, as mandated by the libavformat
documentation.
Fixes http://bugs.musicpd.org/view.php?id=4446
If the song tag comes from a stream, and MPD playback restarts, MPD
would believe the tag should override the newly received tag. This
makes the previous tag appear stuck. This change passes the song tag
only if it's authoritative - i.e. if it's a song file.
Right after booting, the monotonic clock starts with a very small
value, and AudioOutput::LockUpdate() may believe that the fail_timer
has not recovered yet.
Ask FFmpeg to seek to the next packet boundary *before* the seek
position, so we don't miss audio data. Now we get too much, but we'll
solve that in the next commit.
