Frederic Vanden Poel | 27 Nov 00:36 2014

432 EVO has been made possible thanks to mpd


Our 432 EVO music server has been made possible thanks to certain 
features in MPD that allow us to do our DSP postprocessing.
Not many players support what we want, but squeezelite is another one 
where our 432 Hz method already works in the lab, and also allows access 
to other sox recipes as proposed by my earlier mpd patch.

For the moment we still use mpd.

The EVO has been nominated by the three leading Dutch hifi magazines, FWD magazine and Music Emotion to participate in the election 
for "network player of the year 2014":

The 432 EVO is nr 5 in this list, and the sound quality has been 
improved thanks to more recent MPD versions like 0.18.13 and 0.19.X 
which sound better than what VB 2.2 is using (mpd 0.17.4).
On vortexbox 2.2 the difference between the latest MPD playing directly 
from HDD and playing via LMS + vortexbox-player + MPD is day and night.

So this is a thank you mail from Klinkt Beter and 432 EVO for the 
progress MPD has made over the last years!


Best regards,

Frederic Vanden Poel

(Continue reading)

Nix | 24 Nov 14:02 2014

[PATCH] Output: start with a null mixer.

There are code paths (mostly error cases) in which it is possible to
initialize an AudioOutput and then kill it without ever calling
audio_output_new().  In such a case, its destructor will attempt to
free a mixer that was never initialized, leading to an attempt to
take out a lock on a mutex that was similarly never initialized,
which hangs forever.

Fix by always initializing the mixer appropriately.
 src/output/Init.cxx | 1 +
 1 file changed, 1 insertion(+)

This bug made it hell to get a Shoutcast stream initialized: I forgot
that you need the quality and format even for a flac stream (!) but
rather than giving me an error in the log, I got this (here from a
copy of mpd instrumented with alloc/free logging so you can see the
bug in action, an output init with a garbage mixer, then an attempt
to free that mixer and lock a garbage mutex):

audio output init: mixer is 0x6ca470
freeing mixer: 0x6ca470
mixer_close: mixer lock takeout
Locking 0x6ca488 <at> 0x6ca488
# hangs forever
Program received signal SIGINT, Interrupt.
0x00007fffefacf86c in __lll_lock_wait () from /lib/
(gdb) bt
#0  0x00007fffefacf86c in __lll_lock_wait () from /lib/
#1  0x00007fffefacb517 in _L_lock_574 () from /lib/
(Continue reading)

Jörg Krause | 22 Nov 15:38 2014

MPD locked by state file

Hi all,

I'm running into the following issue:

I've a wireless audio device running as a media renderer using latest
MPD version and upmpdcli as UPnP front end. I can connect to the device
with several UPnP clients like Streambels and BubbleUPnP running on my
Android device.

If I play an audio file with, eg. Streambels, and I shutdown MPD while
playing, MPD saves its state in the state file. One of the data stored
is song_begin:

Now, if I shutdown Streambels, (re)start MPD and try to access MPD with
another client, eg. BubbleUPnP, curl is complaining about a refused
connection to the port 9989 (which was the port of Streambels -
BubbleUPnP uses a different port). I can see the UPnP media renderer in
Bubble and also press the play button, but it actually never starts to
play. I suppose that MPDs state is somehow locked now to the previous
UPnP client Streambles.

To get access with BubbleUPnP I have to delete the state file and
restart MPD.

I'm not sure how to handle this and I would be glad about any comment or
advice. I had a quick look at the sources of MPD and I've found the
piece of code in src/input/plugins/CurlInputPlugin.cxx:RequestDone()
where the error of curl is displayed to the user, but AFAIU the errors
are not handled.

(Continue reading)

Jon Ferguson | 20 Nov 19:55 2014

Thank you

Just wanted to write a quick note to all the MPD devs to say: Thank you.

I've been using MPD in my own project,, which I went public with today on Hacker News. It certainly wouldn't have been possible without the most fabulous MPD.

I know it can be a thankless endeavor sometimes, so thank you for developing and maintaining such an excellent program!

Jon Ferguson

mpd-devel mailing list
mpd-devel <at>
Michael Blumenkrantz | 12 Nov 05:18 2014

Updated/Added files listing


I asked on IRC about this and didn't get a definitive answer. I'm currently working on an MPD client, and, as a
feature, I would like to have the ability to automatically add to the queue any songs as they are added to the
MPD database (inotify updating).

I'd rather not do something hacky like trying to parse the log file, but it seems that there's no other way to
get information about files that have been updated or added to the database.

The suggestion that I did receive, which was almost functional for this purpose, was to use a
"modified-since" filter on a find/search command. Unfortunately, this only shows the file's last
modification date and has nothing to do with server updates. If a file which was last modified a year ago is
suddenly added to the database, it's last modified date will still be last year, and so it seems that this is
not quite what I'm looking for.

Is there some way to get this info using the protocol?

mpd-devel mailing list
mpd-devel <at>
Ted Yin | 13 Nov 03:09 2014

Hi! I'd like to contribute to MPD dev

Hi everyone,

I’m a fanatic MPD user. Recently I’m interested in providing with extra functionalities instead of solely using the software. My first try is to write a client which triggers a command when MPD changes its state: It’s simple, actually I just spent two afternoon working on it. Now I’m motivated to try something more challenging. As I remember, since I started to use MPD, I have wished if there could be a fade in/fade out effect when a song starts to play or is being paused, which will definitely more comfortable to users’ ears. Actually, as I know, there is a “cross fading” effect already incorporated into MPD. However, the simple fade in/fade out effect is still missing. So I wonder if I could implement that. As a junior college student, I couldn’t guarantee being always working on it. But maybe when I get free weekends, things would be done very soon. 

Should I start from reading the doc inside the project root directory? 


Ted Yin
mpd-devel mailing list
mpd-devel <at>
Rory McNamara | 11 Nov 17:15 2014

[Patch] Least unambiguous commands.

Hi, I've written a patch to allow you to run a command based on the least unambiguous portion of the command name. For example, prev can be called with pr, pre or prev, but not p becuase of play and playlist.

The patch is attached.

Rory McNamara
Attachment (least_unambiguous.patch): text/x-patch, 2545 bytes
mpd-devel mailing list
mpd-devel <at>
Misty De Meo | 11 Nov 04:38 2014

[PATCH] Main: fix compilation on OS X using non-Apple compilers

Commit d42c0f1dc5063d50a62817b63a1c2a4507c46071 added an OS X-specific
method of calling mpd_main_after_fork(), which uses Grand Central
Dispatch. Since this uses a block literal, it breaks compilation on
compilers which don't support the block extension, e.g. non-Apple
compilers. This affects users on older OS X releases with GCD (which
depend on older Clang releases, or Apple GCCs, which don't support the
C++11 features MPD needs); or which don't support GCD at all (10.5 and

The attached patch changes the #ifdef so that the non-GCD code is used
as it was on OS X before this patch if blocks aren't available, via
checking __BLOCKS__ macro.

mpd-devel mailing list
mpd-devel <at>
Michael Paquier | 5 Nov 13:27 2014

Small doc patch for mpc

Hi all,

While looking at the documentation of mpc, I found a small typo. Patch is attached.
mpd-devel mailing list
mpd-devel <at>
Max Kellermann | 3 Nov 08:37 2014

Re: patch for extra sox recipes in SoxrResampler.cxx

On 2014/10/26 15:54, Frederic Vanden Poel <info <at>> wrote:
> Here's a new version. Not sure how to properly format comments in the
> heading lines of the patch, but the info should be
> "add new soxr recipes: libsamplerate equivalent SOXR_LSR0Q, SOXR_LSR1Q
> and SOXR_LSR2Q"

Now where's all the information from your first email?
Max Kellermann | 3 Nov 08:15 2014

Licensing conflict with libmp4v2

Hi Andree,

the Debian project has found a licensing conflict between MPD and libmp4v2:

Because you submitted the plugin to MPD, I'd like you to figure out a
solution.  As I wrote in reply to the Debian bug report, the plugin
must be deleted from MPD (0.19.3) if the libmp4v2 project does not
switch to a license that is compatible with MPD's.