| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Qball, pat, and jat :)
------------------------------------------------------------------------
r6477 | jat | 2007-06-04 19:41:18 +0200 (Mo, 04 Jun 2007) | 4 lines
Don't initialize zeroconf until after we've daemonized and log output has
been redirected. This prevents zeroconf from blocking daemonization, and
makes sure any errors get sent to the logs and not stdout.
------------------------------------------------------------------------
r6474 | jat | 2007-06-03 22:09:12 +0200 (So, 03 Jun 2007) | 3 lines
Adding ChangeLog entry for zeroconf_enabled, adding Zeroconf section to
mpdconf.example, and updating the zeroconf_* docs.
------------------------------------------------------------------------
r6471 | jat | 2007-06-03 21:44:19 +0200 (So, 03 Jun 2007) | 4 lines
Define HAVE_ZEROCONF if Avahi or Bonjour support is enabled, so that we can
silence a warning about an unused variable without using stupid checks for
HAVE_AVAHI || HAVE_BONJOUR.
------------------------------------------------------------------------
r6467 | pat | 2007-06-03 20:08:51 +0200 (So, 03 Jun 2007) | 2 lines
allow zeroconf to be disabled.
------------------------------------------------------------------------
r6464 | jat | 2007-06-03 02:03:20 +0200 (So, 03 Jun 2007) | 2 lines
Cleaning up zeroconf configure magic.
------------------------------------------------------------------------
r6463 | jat | 2007-06-03 00:58:51 +0200 (So, 03 Jun 2007) | 2 lines
Check if we need -ldns_sd for Bonjour.
------------------------------------------------------------------------
r6462 | jat | 2007-06-03 00:52:53 +0200 (So, 03 Jun 2007) | 2 lines
Adding a missing include.
------------------------------------------------------------------------
r6453 | pat | 2007-06-02 19:06:08 +0200 (Sa, 02 Jun 2007) | 3 lines
Added Bonjour zeroconf support. This works now natively on
MacOS X. 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/branches/branch-0.13.0-fixes@7381 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From <http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions>:
> .oga - audio/ogg
>
> * Ogg Audio Profile (audio in Ogg container)
> * Applications supporting .oga, .ogv SHOULD support decoding
> from muxed Ogg streams
> * Covers Ogg FLAC, Ghost, and OggPCM
> * Although they share the same MIME type, Vorbis and Speex
> use different file extensions.
> * SHOULD contain a Skeleton logical bitstream.
> * Vorbis and Speex may use .oga, but it is not the
> prefered(sic) method of distributing these files because of
> backwards-compatibility issues.
Thanks to Qball and Rasi for the patch.
https://svn.musicpd.org/mpd/trunk r7191
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7380 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
| |
The database parser does not check whether the song object has been
initialized yet, which may lead to a NULL pointer dereference. Add
this check.
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7379 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
strtok() may return NULL if the input is an empty string. The
playlist parser did not check for that.
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7378 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize audioOutput->data with NULL in jack_initDriver().
Previously, this was never initialized, although the other functions
relied on it being NULL prior to jack_openDevice().
This patch addresses bug 0001641[1]. In contrast to the patch provided
by the bug reporter, it moves the initialization before the "!param"
check.
[1] - http://musicpd.org/mantis/view.php?id=1641
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7377 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
| |
This patch was taken from
http://bugzilla.livna.org/show_bug.cgi?id=1987 and addresses bug
0001693[1]
[1] - http://musicpd.org/mantis/view.php?id=1693
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7376 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
There are still other ways to run the mpd server out of disk-space,
so permissions are still recommended to protect against malicious
users.
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7178 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
If we keep processing expired interfaces in a loop,
we'll eventually close it and get fd < 0, causing
assertions to fail.
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7175 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/branches/branch-0.13.0-fixes@7174 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
From sbh, r7041 and r7042 from trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7173 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7170 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
From qball, r7077 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7169 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While mpd has always protected against the infinite expansion of
the main playlist by limiting its size in memory, however the
new storedPlaylist code has never checked for this limit.
Malicious (or clumsy) users could repeatedly append songs to
stored playlists, causing files to grow increasingly large
on disk. Attempting to load extremely large files into memory
will require mpd to slurp that all into memory, and ultimately
the file would be unusable by mpd because of the configurable
playlist size limit.
Now we limit stored playlists to the max_playlist_length
configuration variable set by the user (default is 16384). We
will refuse to append to playlist files if they hit that limit;
and also refuse to load more than the specified amount of songs
into memory.
r7154 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7165 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
r7108 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7164 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
error. this was caused by always having the handleStoredPlaylist function return 0.
From qball, r7105 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7163 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
r6874 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7162 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
(when users press stop, previous snd_pcm_drop(), then snd_pcm_drain() was called. this would lockup dmix)
From shank, r6517 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7161 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.
From: jat, r6828 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7160 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.
r6843 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7159 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
|
| |
This should fix Debian bug #428551
(mpd crashes when restarting the dbus daemon)
r6844 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7158 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
|
|
| |
We shouldn't try to continue if mpc_decoder_initialize() fails.
r7113 in trunk
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7157 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
A different, cleaner fix was used in trunk.
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@7156 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/branches/branch-0.13.0-fixes@6897 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6323 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6290 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6289 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6278 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
|
|
|
|
|
| |
call to FATAL().
git-svn-id: https://svn.musicpd.org/mpd/trunk@6276 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6275 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6274 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
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6271 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6270 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6269 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
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6265 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
segfaults.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6264 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6263 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
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6246 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6245 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
|
|
| |
can't be loaded anyway).
git-svn-id: https://svn.musicpd.org/mpd/trunk@6244 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6232 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6230 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
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6225 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
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6200 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
| |
git-svn-id: https://svn.musicpd.org/mpd/trunk@6199 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|