DECODE_STATE_STOP is always set as dc->state, and dc->stop
is always cleared. So handle it in decodeStart once rather
than doing it in every plugin.
While we're at it, fix a long-standing (but difficult to
trigger) bug in mpc_decode where we failed to return
if mpc_decoder_initialize() fails.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7122 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Although most PATH_MAX is higher than the 1k buffer we set, some
implementations will set a 256 (or even 64) byte PATH_MAX, so
we should be prepared for that.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7121 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Abstractions should reduce the amount of code and make things
easier to follow. The StoredPlaylist struct did not do that, so
get rid of it and just use our standard linked list
implementation instead.
diffstat agrees with me that the abstraction is pointless:
3 files changed, 60 insertions(+), 90 deletions(-)
git-svn-id: https://svn.musicpd.org/mpd/trunk@7120 09075e82-0dd4-0310-85a5-a0d7c8717e4f
* stop supporting unused parentlen block, I have no idea how it
was ever usable, but playlists don't work in subdirectories...
* myFgets is far easier to use than fgetc loops.
* Since we're using myFgets, we'll just skip lines that are too
long, rather than error out and bitch and moan about things...
git-svn-id: https://svn.musicpd.org/mpd/trunk@7118 09075e82-0dd4-0310-85a5-a0d7c8717e4f
It was a nice way to double the memory needed to write the
playlist to a file.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7116 09075e82-0dd4-0310-85a5-a0d7c8717e4f
thread-safety work in preparation for rewrite to use pthreads
Expect no regressions against trunk (r7078), possibly minor
performance improvements in update (due to fewer heap
allocations), but increased stack usage.
Applied the following patches:
* maxpath_str for reentrancy (temporary fix, reverted)
* path: start working on thread-safe variants of these methods
* Re-entrancy work on path/character-set conversions
* directory.c: exploreDirectory() use reentrant functions here
* directory/update: more use of reentrant functions + cleanups
* string_toupper: a strdup-less version of strDupToUpper
* get_song_url: a static-variable-free version of getSongUrl()
* Use reentrant/thread-safe get_song_url everywhere
* replace rmp2amp with the reentrant version, rmp2amp_r
* Get rid of the non-reentrant/non-thread-safe rpp2app, too.
* buffer2array: assert strdup() returns a usable value in unit tests
* replace utf8ToFsCharset and fsCharsetToUtf8 with thread-safe variants
* fix storing playlists w/o absolute paths
* parent_path(), a reentrant version of parentPath()
* parentPath => parent_path for reentrancy and thread-safety
* allow "make test" to automatically run embedded unit tests
* remove convStrDup() and maxpath_str()
* use MPD_PATH_MAX everywhere instead of MAXPATHLEN
* path: get rid of appendSlash, pfx_path and just use pfx_dir
* get_song_url: fix the ability to play songs in the top-level music_directory
git-svn-id: https://svn.musicpd.org/mpd/trunk@7106 09075e82-0dd4-0310-85a5-a0d7c8717e4f
this was caused by always having the handleStoredPlaylist function return 0.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7105 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
