Detect if other clients have sent commands?

Discuss client development (or even MPD development if you feel so inclined), ask questions about the client libs, MPD feature requests from client developers, etc...
Post Reply
Posts: 2
Joined: October 23rd, 2019, 7:07 pm

Detect if other clients have sent commands?

Post by music4j » October 23rd, 2019, 7:17 pm


My MPD installation is controlled by two clients:

1. a program that forwards the commands received from an IR to MPD
2. a script that is executed as cron job.

What I am trying to achieve the following in the cron job script:

"Start playlist X and wait until the user issued any command via IR (the other client). If no command has been recognized after 30 minutes stop playback".

Starting the playlist is of course not a problem, but detecting if there was a user input via IR to MPD the problem I am not able to solve.

Is there some notification system for getting notifications when a different client has sent commands to mpd?
Or a possibility to access the mpd command history of all clients (to check if the last command is the one executed by the cron job script)?

Or is there an alternative way to realize this functionality I don't recognize?

Thanks in advance for any ideas and suggestions.

Forum team
Posts: 953
Joined: January 15th, 2013, 3:43 pm

Re: Detect if other clients have sent commands?

Post by max » October 23rd, 2019, 9:45 pm

You can track MPD's state and you can do explicit client-to-client messages. But you can't detect the actions of other clients directly; you can only detect if another client changed MPD's state.

Why is that second script a cron job? Why not a daemon which listens for "idle" events, tracking MPD's state and guessing whether the IR client has modified MPD's state? Every time a state change was detected, the 30-minute-timer is restarted, and if that timer expires, stop playback.

Posts: 2
Joined: October 23rd, 2019, 7:07 pm

Re: Detect if other clients have sent commands?

Post by music4j » October 27th, 2019, 12:59 pm

Thanks max for your response with valuable ideas.

The current system design is focused on stability. The only component that have to be running and alive for the cron job to be able to work correctly is MPD (and the system parts it depends on). Everything else can crash but the wake-up cron job will still work.

Polling the state is indeed an option. However the idle command looks exactly what I was searching for.

Limiting it to the subsystems "player playlist mixer" covers exactly all the actions I had in mind.
Unfortunately in my tests this did not work so well. The events "playlist" and "player" are firing very frequently even without any user interaction.
I assume this happens because the playback item is a internet radio stream for local mp3 track this does not happen. "playlist" and "player" seems to fire when the transmitted title name changes.

For "player" I don't understand this, as the mpd documentation states, that this event triggers when "the player has been started, stopped or seeked". Just playing an internet stream should not trigger this (my mpd is 0.19.21-1 on Raspbian stretch).

Post Reply