If a song with an absolute path points inside the music directory,
print only the relative part. This happens when partial songs from a
playlist file were loaded.
I've already changed the "playlistinfo" command to hide HTTP
passwords, but forgot to do the same for the simpler "playlist"
command. This patch changes queue_print_uris() to use the code from
song_print_uri().
MPD doesn't have child processes anymore, and thus we're not expecting
to receive SIGCHLD very often. Since hard disk access isn't
interrupted by signals anyway, we don't need those excessive checks.
The function playlist_metadata_load() will overwrite the input buffer
before using the "name" parameter; since "name" points to the same
buffer, we'll get a corrupted string.
Some users reported that MPD crashes when using a new CURL version
with the threaded DNS resolver enabled. It seems that
curl_multi_fdset() returns no file descriptor when the DNS resolver
runs in another thread, so MPD does not have any event to wait for.
On the CURL mailing list, somebody suggested to sleep for a fixed
amount of time. This is not an elegant solution, because daemons
should never have to sleep without waiting for an event. I hope the
CURL developers will review the API and remove the threaded DNS
resolver.
Meanwhile, I'm removing the assertion in question, to allow those
unfortunate users running the latest CURL version to continue using
MPD.
In libwildmidi 0.2.3, the function WildMidi_SampledSeek() was removed,
without changing the SO name. This patch adds an autoconf check for
that function. Fall back to WildMidi_FastSeek() if
WildMidi_SampledSeek() is not available anymore.
libavformat 0.6 does not pass the original URI pointer to the "open"
method, which leads to a crash because MPD was using a dirty hack to
pass a pointer to that method.
This patch switches to av_open_input_stream() with a custom
ByteIOContext class, instead of doing the URI string hack with
av_open_input_file().
Loosely based on a patch from Jasper St. Pierre.
Use the libavformat function av_probe_input_format() to probe the
AVInputFormat, instead of letting av_open_input_file() do it
implicitly. We will switch to av_open_input_stream() very soon, which
does not have the probing code.
Loosely based on a patch from Jasper St. Pierre.
libavformat 0.6 does not pass the original URI pointer to the "open"
method, which leads to a crash because MPD was using a dirty hack to
pass a pointer to that method.
This patch switches to av_open_input_stream() with a custom
ByteIOContext class, instead of doing the URI string hack with
av_open_input_file().
Loosely based on a patch from Jasper St. Pierre.
Use the libavformat function av_probe_input_format() to probe the
AVInputFormat, instead of letting av_open_input_file() do it
implicitly. We will switch to av_open_input_stream() very soon, which
does not have the probing code.
Loosely based on a patch from Jasper St. Pierre.
I've attached a patch that will make file URIs work on operating systems
that provide the getpeereid() function call to check the user ID of the
peer connected to a UNIX domain socket.
I took this tag name from a MusePack sample file I got from a user.
It is not documented in the APE specification:
http://wiki.hydrogenaudio.org/index.php?title=APE_key
People seem to be using undocumented extensions to the specification
anyway, and the best we can do is attempt to support them.
The new function playlist_open_any() combines playlist_mapper_open(),
playlist_list_open_uri() and playlist_list_open_stream(), providing an
easy API for all of them.
Merged both loops into playlist_list_open_stream(). This is needed
because playlist_list_open_stream() needs to know the MIME type, which
is only known after the stream has become "ready".
This buggy implementation failed to allow "..." sequences, because the
dot count was always zero. The usefulness of allowing "..." (or more
dots) is debatable, but since it's a valid file name, we allow it.
libcue's track_get_length() returns 0 for the last track, because that
information is not available in the CUE sheet. This makes MPD quit
playing the last track immediately. If we set "song.end_ms=0", MPD
will play the track until the end of the song file, which is what we
want.
I've attached a patch that will make file URIs work on operating systems
that provide the getpeereid() function call to check the user ID of the
peer connected to a UNIX domain socket.
this greatly improves performance of commands that return a lot
of data, e.g. search results or recursive content of a directory,
while being connected to local mpd via tcp/ip socket.
Memory leak fix. The input_stream object passed to
playlist_list_open_stream_suffix() must be closed by the caller - this
however never happens in playlist_list_open_path(), because it does
not return it to the caller.
Pass sizeof(buf) to decoder_data(), not the number of samples (which
is half the size). At the same time, pass GME_BUF_SIZE to gme_play()
- libgme really wants to get the number of samples, not the number of
stereo frames. Previously, this plugin had been using only the first
half of the buffer.
This is probably unsafe, and doesn't protect against symlink loops,
but we will eventually add this when we bring update*.c and inotify*.c
closer together.
This shouldn't really happen, but insane users might delete/rename the
music directory while MPD runs. What was even more insane was that
MPD crashed due to this. This is a workaround - there is currently
nothing useful we can do in this case; except maybe poll for the music
directory to reappear, but that's too much trouble for a user error.
I took these tag names from a MusePack sample file I got from a user.
These are not documented in the APE specification:
http://wiki.hydrogenaudio.org/index.php?title=APE_key
People seem to be using undocumented extensions to the specification
anyway, and the best we can do is attempt to support them.
Reduce the overhead. Most buffers used by MPD are around 2 to 4 kB.
8 kB seems large enough to keep heap fragmentation low.
Additionally, this patch fixes an off-by-one error in the alignment
formula.
On mingw32, snprintf() expects a 64 bit integer instead of a "long
int" for "%li" - this is not consistent with our expectation, so we're
using plain sprintf().
For some unknown reason, read() blocks on WIN32, even though it was
invoked inside the G_IO_IN callback. By switching to GIOChannel
functions, this problem is solved, and it works on both Linux and
Windows.
On WIN32, use g_io_channel_win32_new_fd() instead of
g_io_channel_unix_new(). There doesn't seem to be a practical
difference, but it seems more correct.
In mingw32, int16_t is not defined by sys/types.h, but it is by stdint.h,
and it is in the int16_t man page as being defined in stdint.h. Thanks to
mithi for help debugging.
Don't add it to the filter chain, because we need to apply replay gain
before cross-fading with the next song. Add a second replay_gain
filter which is used for the song being faded in (chunk->other).
