Remove the decoder dependency on player_control. All player_control
was needed for is to signal the player thread, and we can do that with
a simple GCond as well.
Allocate a player_control object where needed, and pass it around.
Each "client" object is associated with a "player_control" instance.
This prepares multi-player support.
When a music_chunk to be crossfaded consists only of a tag,
cross-fading is not possible, and led to an assertion failure. This
patch just discards those, as if cross-fading was not enabled.
Until the decoder plugin has called decoder_initialized(), the player
may not submit seek commands. This however could occur with a slow
decoder and a CUE file with a virtual song offset. This patch adds
another check.
When one song is played twice, and the decoder is working on the
second "instance", but the first should be seeked, the check in
player_seek_decoder() may assume that it can reuse the decoder without
exchanging pipes. The last thing was the mistake: the pipe pointer
was different, which led to an assertion failure. This patch adds
another check which exchanges the player pipe.
Replaced all occurrences of g_error() with MPD_ERROR() located in a new header
file 'mpd_error.h'. This macro uses g_critical() to print the error message
and then exits gracefully in contrast to g_error() which would internally call
abort() to produce a core dump.
The macro name is distinctive and allows to find all places with dubious error
handling. The long-term goal is to get rid of MPD_ERROR() altogether. To
facilitate the eventual removal of this macro it was added in a new header
file rather than to an existing header file.
This fixes#2995 and #3007.
Previously, tags of the new song being cross-faded in were sent
immediately. That can cause wrong information being displayed,
because the "previous" song might send its tag at the end again,
overriding the "next" song's tag. This patch saves & merges the tag
of the next song, and sends it when cross-fading is finished, and the
next song really starts.
Did you ever accidently click "stop" while feeding a radio station?
This option sets the output device to "pause" to disable the "close"
method. It falls back to "pause" then, which is specific to the
plugin. Some plugins implement it by feeding silence.
Another quirk fixed: after the last chunk of a song has been played,
the "elapsed_time" variable is set to the chunk's time stamp. When
the client receives the PLAYER idle event and asks MPD for the current
time stamp, MPD will return the last time stamp of the previous song
when it hasn't played the first chunk of the current song yet.
Seek the decoder to the start of the range before beginning with
playback. Stop the decoder when the end of the range has been
reached. Add the start position to the seek position. Expose the
duration of the range, not the full song file.
When waiting for the decoder to provide more data, the player thread
generates silence chunks if needed. However, it forgot to initialize
the chunk.times attribute, which had now an undefined value. This
patch sets it to -1.0, meaning "value is undefined". Add a ">= 0.0"
check to audio_output_all_check(). This fixes spurious relative
seeking errors, because sometimes, the "elapsed" value falls back to
0.0.
After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.
When there's no queued song, and the current one has finished playing,
first make sure that the hardware outputs have really finished playing
the last chunk: call the drain() method in all audio outputs. Without
this patch, MPD stopped playback shortly before the ALSA sound card
had finished playing.
When the decoder finishes the "queued" song very quickly (before the
"current" song finishes playing), an assertion in do_play() fails
because it thinks that it should start decoding the queued song,
although that has in fact just finished.
While paused, the player thread re-locks its mutex and waits for a
signal. This is racy: when the command is set while the thread is
waiting for the lock, it may wait forever. This patch adds another
command check before player_wait().
Use GMutex/GCond instead of the notify library. Manually lock the
player_control object before accessing the protected attributes. Use
the GCond object to notify the player thread and the main thread.
Right after seeking and song change, the elapsed_time shows old
information, because the output thread didn't finish a full chunk
yet. This patch re-adds a second elapsed_time variable, and keeps
track of a fallback value, in case the output thread can't provide a
reliable value.
Don't set the error in play_chunk(); do all the error handling in the
caller. The errored_song attribute isn't set anymore; it doesn't make
sense for PLAYER_ERROR_AUDIO.
With these methods, an output plugin can allocate some global
resources only if it is actually enabled. The method enable() is
called after daemonization, which allows for more sophisticated
resource allocation during that method.
When the audio output fails to open, MPD pauses playback, but doesn't
reset player.play_audio_format. This leads to an assertion failure in
audio_output_all_check() on the next REFRESH command, because no audio
output is open.
Tracking the "elapsed" time from the chunks which we have sent to the
output pipe is very imprecise: since we have implemented the music
pipe, we're sending large number of chunks at once, giving the
"elapsed" time stamp a resolution of usually more than a second.
This patch changes the source of this information to the outputs. If
a chunk has been played by all outputs, the "elapsed" time stamp is
updated.
The new command PLAYER_COMMAND_REFRESH makes the player thread update
its status information: it tells the outputs to update the chunk time
stamp. After that, player_control.elapsed_time is current.
