db_get_song was being called once for all sub-handlers, but with the
addition of the find command, we don't have a URI coming in, so doing
db_get_song once won't work anymore.
[mk: fixed initialization order]
On both locations, the result of write() can be ignored safely. In
event_pipe_emit_fast(), that can only be "EAGAIN", which means that
the pipe buffer is full - no further notification required. In
client_init(), that would be a fatal connection error, which would be
caught by the next event.
This patch fixes gcc warnings.
Cuesheets are often saved as vorbis comment
flac files (CUESHEET=.. case doesn't matter).
We can parse this now and use the information to
tag the subtracks (from the embedded cuesheets).
With these methods a tag struct can be created
from the cdtext information in a cue sheet.
The methods depend on a cue parsing library.
Reading from strings (char*) as well as from
a file (FILE*) is supported.
This is a little ugly, but as nextSongInPlaylist is both called when
queued is update (in case playlist ended) and for user "next" command,
there isn't any other (simple) solution
Previous cast to float didn't have any effect because one value is uint
and the other is a floating type but the number itself is even..
This caused some tracks to end before they were really at an end.
The strings passed to tag_pool_get_item() are not null-terminated, and
the caller passes the string length. Don't assume it is
null-terminated anyway by using strcmp().
There are numerous race conditions between the libpulse thread
(pulse_mixer.c callbacks) and the rest of MPD. Protect the volatile
attributes of the pulse_mixer struct with a mutex to fix that.
Don't mess with pulse_mixer.volume for setting the volume. This
variable should only be used to transfer the current volume from
sink_input_vol() to pulse_mixer_get_volume().
The pa_context_get_sink_input_info() function is asynchronous, and
after it returns, libpulse does not guarantee that the operation has
completed yet; in fact, it is not likely. Explicitly wait for the
operation to complete.
The code for the new pulse_wait_for_operation() function was inspired
by mplayer and xine code.
The function mixer_failed() expects the mixer mutex to be already
locked, yet it calls mixer_close(), which attempts to lock the mutex
again, deadlocking itself.