Rewind to a set number of seconds when paused

[Genues]

It would be convenient to be able to rewind to the number of seconds set in the settings. When an audiobook is played, it would allow you to recall what was in the book earlier.

[borine]

Surely this is a function of the client, not of mpd? For example, using mpc as my client, to replay the last 30 seconds when starting after a pause, I can do:

mpc pause
mpc seekthrough -30
mpc play

[Genues]

It's possible on the client, of course, but it's easier to press a single pause button on the client than to write three commands like in your example.
I use different clients, and for example, in the M.A.L.P. Android client, it's quite difficult to rewind 30 seconds, especially when driving. When you receive a call, the app automatically pauses and resumes after the call ends, and it would be convenient if it automatically shifted n seconds back.
As a temporary solution, I wrote this not-so-good code, but maybe the developers will do it right. Thank you.

diff --git a/src/player/Thread.cxx b/src/player/Thread.cxx
index 1a9de723..8ef8e4e1 100644
--- a/src/player/Thread.cxx
+++ b/src/player/Thread.cxx
@@ -791,6 +791,10 @@ Player::ProcessCommand(std::unique_lock<Mutex> &lock) noexcept
        case PlayerCommand::PAUSE:
                paused = !paused;
                if (paused) {
+                       if (output_open){
+                               SeekDecoder(lock, (pc.elapsed_time.ToDoubleS() > 10 ? SongTime::FromS(static_cast<double>(pc.e
lapsed_time.ToDoubleS()-10)) : SongTime::zero()));
+                       }
+
                        pc.state = PlayerState::PAUSE;

                        const ScopeUnlock unlock(pc.mutex);

[borine]

OK, I understand the requirement for this function, but I still think it is a function which belongs in the client. If your chosen client (M.A.L.P or any other) cannot allow you to do this in a convenient way then I think you should raise it as a feature request with the client developers. I for one would certainly not want this to be the enforced behavior of the mpd service, which is what your patch would do.

[Genues]

Of course, this should not be a forced feature. I thought that it should be done so that if the pause offset is 0 in the settings (by default), then the mpd behavior should be the same as it is now, as without this option.
As for contacting customer developers, I think that this should be implemented in one place, not in several. Since I use different clients, it would be more convenient to implement it on the server side.
I'm not insisting, it just seems to me that such an option would be convenient. That there are other people with the same mpd usage scenario as me.

[borine]

I think that this should be implemented in one place, not in several

So you could implement it in a client running on the mpd server. As a proof of principle, try this simple shell script. Note that mpc is not ideal for this task as there is a slight risk of missing some status changes; and a program written in python, C, C++ etc would be more reliable and efficient. But I think this script is easy to read and use:

#!/bin/sh

REPLAY_SECS=10

new_state=$(mpc status "%state%")
while : ; do
	old_state="$new_state"
	mpc idle player >/dev/null
	new_state=$(mpc status "%state%")
	if [ "$old_state" = playing -a "$new_state" = paused ] ; then
		mpc -q seek -$REPLAY_SECS
	fi
done

[Genues]

I agree that it's not a good solution. In fact, I think it was a poor decision; this is just a band-aid fix.
Could you help me modify my simple code to read the time offset from a settings file?

[borine]

Could you help me modify my simple code

No, you are on your own with that one. Perhaps some of the "other people with the same mpd usage scenario" would like to write some code? If I needed this I would write it as a client; but I do not need it.

[Genues]

I understand, thank you for the discussion.