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
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
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
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
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
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
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
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
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
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
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
The shout plugin will now feign playback until the connect timeout is hit,
preventing connection attempts from blocking playback on local outputs.
Note that this patch is very different from remiss' original one.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6738 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Previously, the warning log was only flushed if creating the db or logging
to stdout. This meant that under normal circumstances (no db creation,
logging to files) the warning log was never flushed. This caused a bug
when a warning was printed for each call to the status command where the
warning buffer would grow endlessly, eventually using more and more CPU to
reallocate it.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6660 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Turns out the fix was as simple as specifying the OPEN_TAGS flag when
opening the file. Thanks again to Kodest for figuring this one out.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6657 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This ReplayGain code is currently disabled because WavpackGetTagItem can't
seem to find replaygain_* fields in APEv2 tags (which is how wvgain stores
ReplayGain values). Additionally, because APEv2 tags are stored at the end
of the file, this code is only implemented for regular files and not HTTP
streams. Using HTTP seeking it *may* be possible to implement it for both.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6656 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Only wavpack implements both fileDecodeFunc and streamDecodeFunc, and it's
fileDecodeFunc provides more functionality. So try using that first.
This commit also fixes a bug where the plugin test loop wouldn't break once
a suitable plugin was found if it used fileDecodeFunc.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6655 09075e82-0dd4-0310-85a5-a0d7c8717e4f
if the clock ticks right after we get the start time and the timeout is
only one second, we'll still wait a full second instead of returning
immediately.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6557 09075e82-0dd4-0310-85a5-a0d7c8717e4f
pretending to play while we wait for the connection to timeout. This
removes the need for timers, and thus removes the now unnecessary
timer_get_runtime_* function(s) from the timer code.
The changes made compared to the pre-patch shout plugin are:
* Block while connecting, timing out after 2 seconds.
* Close the device, and not just the connection, if play returns -1.
* Remove sd->last_err (it's always assigned before use).
* Some minor cleanups.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6555 09075e82-0dd4-0310-85a5-a0d7c8717e4f
outputs, which is actually desired behaviour. This way if the shout server
takes a while to respond, the shout output can block until connected
without messing up other audio outputs.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6554 09075e82-0dd4-0310-85a5-a0d7c8717e4f
leave it in that state. Likewise, if an audio output is in state
DEVICE_ON, and reopening the device due to a format change fails, change it
to state DEVICE_ENABLE. This will prevent flushAudioBuffer from even
attempting to play audio on a closed device (even though it would fail
anyway).
git-svn-id: https://svn.musicpd.org/mpd/trunk@6529 09075e82-0dd4-0310-85a5-a0d7c8717e4f
top depending on !quit, which doesn't set it anywhere before the if (quit)
block is reached, and the inner one which doesn't set quit at all. Since
it's a local variable and can't be modified externally, it'll never be hit.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6524 09075e82-0dd4-0310-85a5-a0d7c8717e4f
* Wait ten seconds before declearing the shout server unreachable
* Fix a state where it would never attempt to connect if it had previously failed
It isn't perfect yet, but I'd like some testing on it from other setups
git-svn-id: https://svn.musicpd.org/mpd/trunk@6523 09075e82-0dd4-0310-85a5-a0d7c8717e4f
state (when users press stop, previous snd_pcm_drop(), then
snd_pcm_drain() was called. this would lockup dmix)
git-svn-id: https://svn.musicpd.org/mpd/trunk@6517 09075e82-0dd4-0310-85a5-a0d7c8717e4f
completely stopped. Instead, send them SIGSTOP to pause the process until
they're needed again. Then send them SIGCONT instead of re-spawning them.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6485 09075e82-0dd4-0310-85a5-a0d7c8717e4f
some versions of shoutcast send "content-type" in all lowercase, and I
don't trust other servers to get the case right for the rest of the headers
we look for.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6482 09075e82-0dd4-0310-85a5-a0d7c8717e4f
have any effect until the aac and mp4 input plugins actually support a
stream decoding API.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6481 09075e82-0dd4-0310-85a5-a0d7c8717e4f
been redirected. This prevents zeroconf from blocking daemonization, and
makes sure any errors get sent to the logs and not stdout.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6477 09075e82-0dd4-0310-85a5-a0d7c8717e4f
header. While this is odd for an HTTP header, it's actually quite common
for streaming clients to send it without a space. Some clients do send
with a space as well, but without one has always worked fine and may in
fact be more compatible.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6472 09075e82-0dd4-0310-85a5-a0d7c8717e4f
silence a warning about an unused variable without using stupid checks for
HAVE_AVAHI || HAVE_BONJOUR.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6471 09075e82-0dd4-0310-85a5-a0d7c8717e4f
I couldn't test mDNSResponder support on Linux, as Debian doesn't include it - but should work as well.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6453 09075e82-0dd4-0310-85a5-a0d7c8717e4f
playback is stopped completely. This means the player process will no
longer have to wake up 100 times per second to see if it's been told to
start playing (the main process will just spawn a new player process when
it needs to). On the downside, this means an extra pair of forks() and the
re-initializing of the player and decode processes each time playback is
restarted.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6446 09075e82-0dd4-0310-85a5-a0d7c8717e4f
one now, and trying to call NULL was causing a segfault at exit.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6398 09075e82-0dd4-0310-85a5-a0d7c8717e4f
uninitialized variables and non-returning functions that return. Let's
tell it to stfu.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6277 09075e82-0dd4-0310-85a5-a0d7c8717e4f
because lsr may return less than the input buffer size, and the rest of the
audio code needs to know the new size. This fixes the clicking that was
introduced with recent changes to the lsr code. A huge thanks to remiss
for figuring this out.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6273 09075e82-0dd4-0310-85a5-a0d7c8717e4f
relative paths in the DB or URLs. The main functional difference is that
playlistmove and playlistdelete will rewrite playlists in the correct
encoding and remove invalid lines instead of potentially modifying them.
The specific changes are:
appendSongToStoredPlaylist:
* Don't convert to FS charset
* Don't prepend music_directory if saving absolute paths
writeStoredPlaylistToPath:
* Convert to FS charset
* Prepend music_directory if saving absolute paths
loadStoredPlaylist:
* Make sure each line is either in the DB or a URL
loadPlaylist:
* Don't bother checking paths, since it's done in loadStoredPlaylist now
git-svn-id: https://svn.musicpd.org/mpd/trunk@6266 09075e82-0dd4-0310-85a5-a0d7c8717e4f
audio at once, so it won't work for us. The old full API code was still
heavily broken, as each call to pcm_convertSampleRate() used the same
state, even if it was processing two streams of audio. The new code keeps
a separate state for each audio stream that's being converted.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6255 09075e82-0dd4-0310-85a5-a0d7c8717e4f
number of channels is specified when the converter state is created.
Previously this was only done once, thus breaking horribly when the input
audio suddenly had a different channel count. A new state could be created
every time the number of channels changes, but this could happen many times
a second if resampling to two different formats at once. The simple API
doesn't have this problem, as channel count is an argument to the
conversion function itself.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6229 09075e82-0dd4-0310-85a5-a0d7c8717e4f
and samplerate conversion. This makes the code much easier to read, and
fixes a few bugs that were previously there.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6224 09075e82-0dd4-0310-85a5-a0d7c8717e4f
playlistadd, playlistdelete, etc. and would've caused the playlist to be
rewritten only up to the line with the error.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6133 09075e82-0dd4-0310-85a5-a0d7c8717e4f
returning a list of matching songs, the number of results and total play
time of the results are returned.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5950 09075e82-0dd4-0310-85a5-a0d7c8717e4f
db file is written. So don't try to set directory_dbModTime to the mtime
of the db file, since it will be incorrect.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5945 09075e82-0dd4-0310-85a5-a0d7c8717e4f
NULL. Doing so would mean future calls to commandError with a socket as an
argument will still write the error message to the error log, and not the
socket.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5891 09075e82-0dd4-0310-85a5-a0d7c8717e4f
message and trailing new line to STDERR_FILENO along with the ACK, instead
of sending them over the socket.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5890 09075e82-0dd4-0310-85a5-a0d7c8717e4f
LOCATE_TAG_KEY_FILE. Specifying "file: " as an argument to
search/find/list wasn't the point of that patch...
git-svn-id: https://svn.musicpd.org/mpd/trunk@5670 09075e82-0dd4-0310-85a5-a0d7c8717e4f
to segfault. This could be exploited by malicious users to crash other
users' mpd. But more importantly, I believe clients are doing this
unintentionally, and that this is what is causing mpd to segfault for many
people after running for long periods of time.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5649 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Mixing code and declarations is ugly, anyways.
We could probably get away with using alloca(), but I'm not sure
how good compiler support is for that, either. It's probably
more supported than mixed declarations and code. Nevertheless;
we'll trigger memory checkers on exit because we don't free
the buffers; but we won't actually leak because we reuse those
buffers (just like the non-SRC code path).
git-svn-id: https://svn.musicpd.org/mpd/trunk@5397 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Avoid unnecessary memset to zero, snprintf always puts a
trailing '\0'. We also have no need to subtract one from the
buffer we're snprintf-ing it to.
We also check the return value of snprintf to ensure it's not
too long. I have a feeling we might as well avoid snprintf
altogether so we don't have to worry about buffer sizing/stack
overflow and just do a bunch of write(2)s, letting Nagle sort it
out...
Also, centralize some of the exit error handling in with
goto. This makes the code a bit more consistent and
maintainable as well as reducing code and binary size.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5395 09075e82-0dd4-0310-85a5-a0d7c8717e4f
We need to identify ourselves as HTTP/1.1 so Range: works;
and so the server can return HTTP/1.1 instead of HTTP/1.0.
Tested against lighttpd 1.4.13
git-svn-id: https://svn.musicpd.org/mpd/trunk@5394 09075e82-0dd4-0310-85a5-a0d7c8717e4f
implementation, and fixing it is a big enough job that I don't know when
I'll get around to it. Probably best just starting from scratch anyhow.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5373 09075e82-0dd4-0310-85a5-a0d7c8717e4f
#2) fix a deadlock condition when attempting to seek if the decoder quit and returned to playerInit()
git-svn-id: https://svn.musicpd.org/mpd/trunk@5325 09075e82-0dd4-0310-85a5-a0d7c8717e4f
size_t (1.1.3) makes a lot more sense, but older flac used unsigned
here...
git-svn-id: https://svn.musicpd.org/mpd/trunk@5258 09075e82-0dd4-0310-85a5-a0d7c8717e4f
just casting to int because it's the simplest (%z is not
well-supported)
Noticed-by: avuton on a 64-bit machine
git-svn-id: https://svn.musicpd.org/mpd/trunk@5257 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Some compilers and linkers aren't smart enough to optimize this,
as global variables are implictly initialized to zero. As a
result, binaries are a bit smaller as more goes in the .bss and
less in the text section.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5254 09075e82-0dd4-0310-85a5-a0d7c8717e4f
We'll be dealing with legacy server configurations for a long
time to come.
git-svn-id: https://svn.musicpd.org/mpd/trunk@5253 09075e82-0dd4-0310-85a5-a0d7c8717e4f
There's no reason they shouldn't be static. Additionally,
output_ports doesn't need to be initialized to NULLs; that is
(and has always been) implicit (for all global variables)
git-svn-id: https://svn.musicpd.org/mpd/trunk@5247 09075e82-0dd4-0310-85a5-a0d7c8717e4f
sendDataToOutputBuffer returns an int (and always has), and
using the existing 'ret' is fine in mp3Read().
git-svn-id: https://svn.musicpd.org/mpd/trunk@5246 09075e82-0dd4-0310-85a5-a0d7c8717e4f
