The updated initialize method did not tell the libFLAC to look for the tag containing the replay information.


git-svn-id: https://svn.musicpd.org/mpd/trunk@7075 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Fixing stopping mpd from block when trying to stop a ogg stream that is buffering.


git-svn-id: https://svn.musicpd.org/mpd/trunk@7053 09075e82-0dd4-0310-85a5-a0d7c8717e4f

unavailable" when streaming music. But give up after 100 times. This is
atm better then waiting until the connection gets back, because mpd
blocks on this.


git-svn-id: https://svn.musicpd.org/mpd/trunk@7052 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7042 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7041 09075e82-0dd4-0310-85a5-a0d7c8717e4f

and with different field types.
This fixes comments for id3v1 and id3v2


git-svn-id: https://svn.musicpd.org/mpd/trunk@7040 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Disable seeking on streams, because of bug 1611. When playing ogg, the decoder seeks through the file then starts to play.  This does not mix well with streams from websites.  Stopping playback of an oggstream that is trying to stream will result in mpd hanging.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7039 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7038 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6952 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This adds the following commands:
* queueid <id>		Add song <id> to the queue.
* dequeue <pos>		Remove song from <pos> from the queue
* queueinfo			List the queue

To the statusfield it adds the following entry:
playlistqueue:	<uid>		UID can be used by clients to track changes in the playlist queue.



git-svn-id: https://svn.musicpd.org/mpd/trunk@6927 09075e82-0dd4-0310-85a5-a0d7c8717e4f

ogg_stream_type_detect may not be compiled correctly
when compiling FLAC (1.1.4+) without Vorbis

git-svn-id: https://svn.musicpd.org/mpd/trunk@6896 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6888 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6874 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Both mp4 and (ogg)flac inputPlugins got HTTP inputStream support
later in the game, so their calls to sendDataToOutputBuffer()
didn't get updated to support buffering while the outputBuffer
was full.  This fixes it.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6873 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6872 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6868 09075e82-0dd4-0310-85a5-a0d7c8717e4f

We want the partial content goodies of HTTP/1.1 without
requiring persistent connections.  Persistent connections across
multiple HTTP requests don't really help in the case of MPD,
either, because our content is usually big and heavy.

Note: this puts MPD at the hands of the server to correctly
close() the TCP connection we're using.  If we connect to a
rogue server that keeps the connection alive even when request
not to, we'll spin :(  However, encountering such a server
is very unlikely...

git-svn-id: https://svn.musicpd.org/mpd/trunk@6867 09075e82-0dd4-0310-85a5-a0d7c8717e4f

We need to SIGCONT the decoder process to allow for seeking
while paused.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6864 09075e82-0dd4-0310-85a5-a0d7c8717e4f

These haven't been used for several years

git-svn-id: https://svn.musicpd.org/mpd/trunk@6863 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The problems I had were related to the OSS driver and USB
device I was using.  The problems existed even with the old
busy-waiting scheme enabled.

OSS  - Bithead USB     => bad
ALSA - Bithead USB     => OK
OSS  - Onboard i8x0    => OK
ALSA - Onboard i8x0    => OK

bad - slow shutdown, pauses, dropped audio after pause/resume

git-svn-id: https://svn.musicpd.org/mpd/trunk@6861 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Until we can fix it properly (or replace it with a cleaner event
system), I don't want this in trunk.  Currently there are
strange pauses when queueing and during shutdown that I can't
seem to figure out right away.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6860 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This fixes the problem of playlist moving/changnig while we're paused

Followup to r6822

git-svn-id: https://svn.musicpd.org/mpd/trunk@6859 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6858 09075e82-0dd4-0310-85a5-a0d7c8717e4f

the force flag will issue FATAL() if an invalid value is
specified

git-svn-id: https://svn.musicpd.org/mpd/trunk@6857 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This way we'll avoid listening on fd=0 and have a better
chance of having fd=0 as /dev/null

git-svn-id: https://svn.musicpd.org/mpd/trunk@6852 09075e82-0dd4-0310-85a5-a0d7c8717e4f

(yes, it helps to actually compile code before committing it)

git-svn-id: https://svn.musicpd.org/mpd/trunk@6851 09075e82-0dd4-0310-85a5-a0d7c8717e4f

We redirect stdin to /dev/null to work around a libao bug, but
this bug has been fixed in libao since 2003 (according to jat).

However, there are likely other bugs in other libraries (and
even our code!) that handle fd=0 incorrectly and I'd rather not
take the risk[1].  So So it's easiest to just keep
fd=0==/dev/null for now...

[1] - I've seen several of these myself...

git-svn-id: https://svn.musicpd.org/mpd/trunk@6849 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This should fix Debian bug #428551
(mpd crashes when restarting the dbus daemon)

git-svn-id: https://svn.musicpd.org/mpd/trunk@6844 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Thanks to _noth_ for the patch, this fixes Mantis bug #1534

_noth_ wrote:
> When MPD is launched from a non-interactive shell, it enters an endless
> loop, filling up its error log file with "error accept()'ing" messages.
> This is caused by the fact that stdin is already closed when mpd starts
> up.  listenOnPort() opens up the first of its sockets as fd 0 (the first
> empty fd table position). Then, setup_log_output()->redirect_stdin()
> overwrites fd0 (fd=open("/dev/null",...); dup2(fd, STDIN_FILENO);)
> without checking if it corresponds to the actual standard input (or if
> it is open in the first place).  This means that listenSockets[0].fd now
> is a fd for /dev/null, thus doIOForInterfaces()->getConnections() can't
> accept(2) on it and fails with the above error. The attached patch fixes
> this for me.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6843 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The host buffer that hostname pointed to is no longer on the
stack by the time the SECURE() message is printed.  So make it
static and thus accessible to all.  We won't be calling this
stuff in the middle of a child process/thread/task, so there's
no

Also, hostname is a constant string we shouldn't modify, so mark
it as const char *.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6842 09075e82-0dd4-0310-85a5-a0d7c8717e4f

For the default: case, just use the error message that libFLAC
provides instead of using something ambiguous.  Also, this gets
rid of long lines in the code, making it easier to digest.

Of course, we save ~100 bytes of text space in the process :)

git-svn-id: https://svn.musicpd.org/mpd/trunk@6830 09075e82-0dd4-0310-85a5-a0d7c8717e4f

We used a bare '15' in several places and it's not immediately
obvious where it came from.  This makes it more obvious

git-svn-id: https://svn.musicpd.org/mpd/trunk@6829 09075e82-0dd4-0310-85a5-a0d7c8717e4f

As unfortunate as it is to remove such useful debugging messages, it's
necessary to fix a potential deadlock with signal handling.  A bunch of
functions the debug functions call aren't safe to call from a signal
handler.  There are some alternate solutions, but they're neither pretty
nor simple.  So just remove them entirely for now.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6828 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Using SECURE once without a \n, and again with one, results in a timestamp
mid-line.  Let's not do that.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6827 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6826 09075e82-0dd4-0310-85a5-a0d7c8717e4f

as with the stop command, this will cause the player and decoder
to suspend and not wake up hundreds of times a second to poll
a variable for wakeup.  This will reduce power consumption
on some CPUs while mpd is paused and not playing.

tests:

pause && unpause => OK

pause && stop && play => OK

pause && exit && restart w/statefile && unpause => OK

pause && block sound device && \
unpause => failed to open sound device \
=> still paused and suspended => unblock sound device &&
unpause => OK (playing)

In all cases, the player process releases the audio device
when paused before going into the suspended state.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6822 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This attribute was set in log.c, but not exported to other
modules in log.h

This allows us to remove some unneccessary variable
initializations that were added in r6277.  I did
audioOutput_shout.c a bit differently, to avoid some
jumps.

before:
$ size src/mpd
text    data     bss     dec     hex filename
225546    4040   14600  244186   3b9da src/mpd

after:
$ size src/mpd
text    data     bss     dec     hex filename
224698    4040   14600  243338   3b68a src/mpd

git-svn-id: https://svn.musicpd.org/mpd/trunk@6821 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@6810 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Parse ReplayGain info in LAME tags and use it if no ID3v2 ReplayGain tags
are found.  This is currently a bit unsafe, as apparently some LAME tags
have bogus ReplayGain values.  But I'm finding a lot of MP3s with valid
LAME tags that fail the LAME tag CRC check.  So until I figure out why
that's happening, it's an unreliable method for checking if the LAME tag is
valid.

A big thanks to tmz for writing the original patch.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6798 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Currently, if we start decoding while the pause flag is set, we open the
audio device and leave it opened, blocking other apps from using it.  The
obvious thing to do is to not open the audio device if the pause flag is
set, but the open call also sets the audio format.  Therefore I'm leaving
the open call in, and just closing it immediately afterwards if the pause
flag is set.

git-svn-id: https://svn.musicpd.org/mpd/trunk@6745 09075e82-0dd4-0310-85a5-a0d7c8717e4f