Good evening,
I believe I have discovered an regression where mpd's response times on the
control socket got slow while playing.
`mpc next`, `mpc previous` or `telnet localhost 6600` and typing next or
previous can take a whole second and a half before mpd responds with OK.
It looks as if mpd is now only polling for commands every second and a half,
instead of reacting immediately.
Bisecting leads to:
45f6129ae7c2b9904b292d8b6b16ea36e9126a86 is the first bad commit
commit 45f6129ae7c2b9904b292d8b6b16ea36e9126a86
Author: Max Kellermann <m...@duempel.org>
Date: Wed Nov 11 16:49:15 2015 +0100
player/Control: don't stop playback in Play()
Instead of stopping playback completely, only CANCEL the queued song
if necessary, and use the SEEK command to play the selected song.
SEEK will take care for current playback state.
:040000 040000 328f83ba03139b5aadce2bff3c8fdc00b3afe9f5
115a2f16251cbb5b44e3e39599319a55bd12371a M src
diff --git a/src/player/Control.cxx b/src/player/Control.cxx
index db8a8b7..2f788ff 100644
--- a/src/player/Control.cxx
+++ b/src/player/Control.cxx
@@ -55,15 +55,7 @@ PlayerControl::Play(DetachedSong *song)
assert(song != nullptr);
const ScopeLock protect(mutex);
-
- if (state != PlayerState::STOP)
- SynchronousCommand(PlayerCommand::STOP);
-
- assert(next_song == nullptr);
-
- EnqueueSongLocked(song);
-
- assert(next_song == nullptr);
+ SeekLocked(song, SongTime::zero(), IgnoreError());
}
void
With the machine completely idle (both CPU and IO), I consistently get this
while playing:
$ time mpc -f '' next
[playing] #215/609 0:00/2:02 (0%)
volume:100% repeat: on random: off single: off consume: off
real 0m1.479s
user 0m0.003s
sys 0m0.000s
strace shows a futex call on the main thread that hangs for approximately 1.4
seconds, which is the delay I observe.
If any more info is needed, I'll be happy to help in any way I can.
Cheers
_______________________________________________
mpd-devel mailing list
mpd-devel@musicpd.org
http://mailman.blarg.de/listinfo/mpd-devel
