IR remote not working correctly with Tidal connect

I’ve just updated to version 2.882 supporting Tidal connect and it works, sort of… but has some issues with IR remote control support on my Pi 4.

Specifically, I can use next track, previous track and pause successfully from the remote control, however pressing the play button does not resume playback and causes a “hang” instead.

After this, the remote control becomes completely unresponsive until a reboot. It also causes the Tidal connect session with my phone to be dropped, although I can reconnect it afterwards. (Albeit with no working remote control)

Looking into this a bit further the issue seems to be with the volumio play command hanging when used with Tidal connect. EG pressing the play button on the remote uses IRexec to execute /usr/local/bin/volumio play - this should trigger playback and return immediately however the process hangs and does not return.

Because the process launched by irexec does not return further remote button presses do not send any commands. If I kill the hanging volumio play process and restart playback via the webUI the remote starts working again - at least for pause / next / previous.

Incidentally, IR support has always been a little bit unstable even with local media playback - if you press skip too rapidly a similar hang can sometimes occur where the remote becomes unresponsive, and I suspect it is also due to this irexec executed process not returning.

I’ve also noticed that volumio seek plus and seek minus commands (+/- 10 seconds) don’t seem to work on the Tidal connect implementation.

It should be possible to reproduce the IR remote problem without an IR remote simply by manually executing the commands normally executed by IRexec from a shell. These can be found below:

### Playback commands ###
begin
prog = irexec
button = KEY_PLAY
config = /usr/local/bin/volumio play
end
begin
prog = irexec
button = KEY_PAUSE
config = /usr/local/bin/volumio pause
end
begin
prog = irexec
button = KEY_STOP
config = /usr/local/bin/volumio stop
end
begin
prog = irexec
button = KEY_PREVIOUS
config = /usr/local/bin/volumio previous
end
begin
prog = irexec
button = KEY_NEXT
config = /usr/local/bin/volumio next
end
begin
prog = irexec
button = KEY_FASTFORWARD
config = /usr/local/bin/volumio seek plus
end
begin
prog = irexec
button = KEY_REWIND
config = /usr/local/bin/volumio seek minus
end
begin
prog = irexec
button = KEY_DELETE
config = /usr/local/bin/volumio clear
end
### Volume commands ###
begin
prog = irexec
button = KEY_VOLUMEUP
config = /usr/local/bin/volumio volume plus
end
begin
prog = irexec
button = KEY_VOLUMEDOWN
config = /usr/local/bin/volumio volume minus
end
begin
prog = irexec
button = KEY_MUTE
config = /usr/local/bin/volumio volume toggle

Hopefully this can be fixed as I tend to use the remote control a lot to control volumio once a playlist is started, and it is still very useful to be able to pause/play/next/previous track with a remote control even with Tidal connect.

This IMHO indicates that it is not an issue with the IR Controller pluigin but with the interaction of Volumio’s command line client and the tidal integration.

From the command line you may check if executing
volumio toggle
works.

That’s what I was saying. It’s not a bug in the IR controller plugin itself but the command line client it uses. (As mentioned this command line client sometimes hangs up if commands are sent to it too quickly, even prior to the Tidal connect implementation - an issue I’ve had ever since I started using a remote, so I just avoid pressing the buttons too quickly…)

The first invocation of volumio toggle while Tidal connect is playing seems to pause playback and return with a success message, the second invocation when playback is paused hangs, does not return and does not resume playback, similar to volumio play, however unlike volumio play it does not cause the Tidal connect connection to terminate as I am able to resume playback via the WebUI whereas if I use volumio play I have to reconnect my phone to Volumio first.

You’re right! :innocent:

A little bit more info I’ve discovered.

If the native playback queue in Volumio is empty, the play button the remote behaves as described above.

However if there is a native playback queue in Volumio already present when Tidal playback is paused, pressing play on the remote (executing volumio play) actually terminates the Tidal connect session and starts playing the normal playback queue!

So there seem to be two separate bugs here:

  1. Pressing play on the remote to resume playback when Tidal connect is paused (but still connected) sends a play command to the native Volumio playback queue instead of the Tidal connect integration. (The play command is being routed to the wrong source)

  2. Pressing play on the remote when the native playback queue is empty causes volumio play to hang and not return, causing the remote control to no longer work until a reboot or the process is manually killed. (This would explain some of the instances of “remote control stopped working” I have seen in the past prior to the Tidal implementation)

Hi, I’m also facing those issues

Sounds like this

Interesting, but I only have the issue with Tidal connect - the play button on a remote works fine with the built in (web UI based) Tidal client and Qobuz clients, local file playback, and as far as I can remember, the Spotify connect (volspot2) plugin. (I cancelled Spotify about a year ago so can’t retest this, but I used to use the remote with it successfully as far as I can remember)

I assume the issue above would only address the “Play is sent to the wrong source” part of the problem - volumio play hanging without returning if there is no playlist to play is a separate issue?

I would think the CLI playback controls should always exit (almost) immediately whether the action is successful or failed? If they don’t, IRexec blocks and won’t send any further commands from the remote control until the blocked process terminates.

1 Like

From Volumio’s terminology there are sources that use MPD (Local file playback, webradio, Tidal, Qobuz etc) and then there are the volatile sources – sources that use stand alone daemons, airplay, Spotify connect and now Tidal connect.

So depending on the currently active source, the API needs to forward the play request to the active plugin. This is currently being done only by the WebUI, but not the REST and other clients.

Hence a “play” command from the IR remote isn’t going to reach Tidal/Spotify Connect, but instead is being sent to MPD.

So the behaviour you see when there are still items in the queue is probably both MPD and Tidal Connect trying to access the playback device the same time, which ALSA will not like very much and is probably complaining. You should be able to tail your logs and check if this is the case…