Volspotconnect2 - Using the Volumio REST API breaks the plugin.

[NicolasBonduel]

Hello,

It seems that if I try to use the Volumio REST API the plugin breaks.

The "pause" (volumio.local/api/v1/commands/?cmd=pause) seems to work, but if I try to "play"(volumio.local/api/v1/commands/?cmd=play) it doesn't work. If I hit play from the Spotify app then, it plays again, but it doesn't reflect in the Volumio UI.

If I hit play from the Volumio UI, then I have two streams playing at the same time.

I'm using the plugin from the master branch.

Thanks for the good work!

[balbuze]

Hi! I assume you ar talking about volspotconnect2, right? (it's because I changed the name of the issue). To be honnest, I never tested Rest API with it... edit : tested, and it does not works as expected...

[ashthespy]

@NicolasBonduel thanks for the issue, from a quick check, it looks like the restAPI calls a different method play method than the normal play that you can toggle from the WebUI

---------------------------- Client requests Volumio play
info: CoreCommandRouter::volumioPlay
UNSET VOLATILE
[SpotifyConnect] unSetVolatile called
[SpotifyConnect] Relinquishing Volumio state to another service, Spotify session: true
[SpotifyConnect] Received stop
info: CoreStateMachine::play index undefined
info: CoreStateMachine::setConsumeUpdateService undefined
info: CorePlayQueue::getTrack 0
info: CoreStateMachine::startPlaybackTimer
info: CorePlayQueue::getTrack 0
info: [1587395340849] ControllerWebradio::resume
info: ControllerMpd::sendMpdCommand play
info: sending command...
info: parsing response...
[Vollibrespot] : volStop

Whereas the WebUI calls the correct volumioVolatilePlay method

info: CoreCommandRouter::volumioVolatilePlay
info: CoreStateMachine::volatilePlay
[SpotifyConnect] Received play
[Vollibrespot] : Event: Play { track_id: SpotifyId { id: 89131653277639963385515684387550311184, audio_type: Track }, position_ms: 92638 }
[SpotifyConnect] Status update:  play
[Vollibrespot] : Event: SinkActive
[SpotifyConnect] Pushing metadata Vollibrespot: true
info: CoreCommandRouter::volumioGetState
info: CoreStateMachine::getState
[SpotifyConnect] Currently active: volspotconnect2
[SpotifyConnect] Pushing new state :: true
info: CoreCommandRouter::servicePushState
info: CoreStateMachine::syncState
info: CoreStateMachine::pushState
info: CoreStateMachine::getState
info: CoreCommandRouter::volumioPushState
info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , saveDeviceInfo
[SpotifyConnect] Sink acquired
info: CoreCommandRouter::volumioGetState
info: CoreStateMachine::getState
[SpotifyConnect] Currently active: volspotconnect2
[SpotifyConnect] Pushing new state :: true
info: CoreCommandRouter::servicePushState
info: CoreStateMachine::syncState
info: CoreStateMachine::pushState
info: CoreStateMachine::getState
info: CoreCommandRouter::volumioPushState

[johnk-]

Hi. I think the same issue may also affect the command line client. If I ssh onto my pi and run volumio stop {"time":1588929234929,"response":"stop Success"} yet my volspotconnect2 track keeps playing. The command line client works fine with a different source. Thanks :-)

[ashthespy]

@johnk- What version of Volumio are you on? (check with cat /etc/os-release) And are you sure works with mpd or other sources are well for stop? From a quick look, it should work with any source..

[johnk-]

cat /etc/os-release VOLUMIO_VERSION="2.773" Ok ... it has started working now. Both using the cli and the REST interface. I didn't even reboot. Very strange. Glad it is fixed though :-)

[ashthespy]

@johnk- the CLI internally just calls the REST api with curl. Stop/Pause should work as usual, but play will fail as mentioned in https://github.com/volumio/Volumio2/issues/1937.

There is a PR https://github.com/volumio/Volumio2/pull/1938 that addresses it, but seems to have slipped through.. Feel free to test it though! :-)

[johnk-]

I started looking into doing this, but I am struggling to work out how to test this without messing up my current setup. I looked at the volumio pull command, but you can't specify an individual commit. I pulled down the source for that commit to my pi, but I am not clear on how to install it. If I just tar up the whole of /volumio is that a good backup? Is there a simple way of installing from the commit I have copied down? Sorry for all the questions. I would like to help, but I am new to this app. Thanks

[ashthespy]

@johnk- You could either just fetch the diff and patch your volumio, or use the volumio pull with my branch. (probably easier) volumio pull -b volatilePlay https://github.com/ashthespy/Volumio2 This backs up the current volumio partition in case things get messy!

[johnk-]

Thank you. Your instructions worked perfectly :-) So far so good with the API and CLI with this version. Next, previous, stop, play and volume commands work perfectly. Toggle is still not working as expected. It stops, but doesn't continue. Toggle followed by a play command does work.

[ashthespy]

@johnk- Could you cross post to the PR so we can track it there? I also pushed a fix for the toggle part.

[johnk-]

Toggle function confirmed as fixed from both the REST API and CLI. I have cross posted this here https://github.com/volumio/Volumio2/pull/1938 Thanks

[illtrick]

I validated that @ashthespy 's fix remedy's the conflict with the IR Remote Controller Plugin I was having.

Initial Setup: Fresh volumio install (v2.806), spotify connect plugin (v1.0.4), IR remote controller plugin (v1.2.4), apple A1294 remote (using this lircd.conf)

Operating Condition: Queued song up using mobile device and selected volumio. All commands issued by mobile device execute as expected. A song was in the "playing" state before testing.

Initial Observed Behavior: Play/Pause/Track controls all operate as expected using volumio web interface. Using an IR remote control Track and Pause commands execute as expected however the Play command does not. It plays the last "non spotify" track. In my case it was a web radio but I'm sure it would be the same if it was a local or network file being played.

Change Made: Executed command volumio pull -b volatilePlay https://github.com/ashthespy/Volumio2 Then rebooted.

Observed Behavior After Change: Play/Pause/Track controls all operate as expected using IR remote.

[basmeyer]

I validated that @ashthespy 's fix remedy's the conflict with the IR Remote Controller Plugin I was having.

Initial Setup: Fresh volumio install (v2.806), spotify connect plugin (v1.0.4), IR remote controller plugin (v1.2.4), apple A1294 remote (using this lircd.conf)

Operating Condition: Queued song up using mobile device and selected volumio. All commands issued by mobile device execute as expected. A song was in the "playing" state before testing.

Initial Observed Behavior: Play/Pause/Track controls all operate as expected using volumio web interface. Using an IR remote control Track and Pause commands execute as expected however the Play command does not. It plays the last "non spotify" track. In my case it was a web radio but I'm sure it would be the same if it was a local or network file being played.

Change Made: Executed command volumio pull -b volatilePlay https://github.com/ashthespy/Volumio2 Then rebooted.

Observed Behavior After Change: Play/Pause/Track controls all operate as expected using IR remote.

1. This fixes the toggle behaviour of Spotify Connect 2 with the command but it could break something else that needs further investigation: Volume control of Spotify on the clients itself (e.g. iPads, iPhones) became unresponsive just after this procedure (not able to reproduce the exact condition after). I could replicate similar behaviour my changing the setting Multi-User Device in the plugin and set it to Off. Spotify would not play audio before the volume slider on Volumio itself was touched for the first time.

2. Also, volume control is always possible with Volumio or via the appropriate REST API commands, but does not synchronize with the volume levels of the Spotify client. When the volume is set differently on Volumio (regardless by REST API) it jumps the volume of the Spotify client. You would expects this to be sync. When Volumio does respond (not situation 1) it syncs allright to the changes on the Spotify client. I further mentioned this issue here: https://github.com/volumio/volumio-plugins/issues/506

[ashthespy]

1. This fixes the toggle behaviour of Spotify Connect 2 with the command but it could break something else that needs further investigation:
   Volume control of Spotify on the clients itself (e.g. iPads, iPhones) became unresponsive just after this procedure (not able to reproduce the exact condition after).
   I could replicate similar behaviour my changing the setting Multi-User Device in the plugin and set it to Off.
   Spotify would not play audio before the volume slider on Volumio itself was touched for the first time.

Hmm, can you share logs when this happens? The daemon utilises the last volume from Volumio, and if this is undefined or 0 then well, this can be the behaviour you describe.

However, this ~is~ should be completely unrelated to the RestAPI for the Play pause part that we use. That path doesn't touch the volume.

[basmeyer]

You are right about the separation and the fact this is unrelated to the REST API. After I went further investigation the volume things I realized this.

About the logs, will do, but at the moment Volumio almost completely died tonight... Because the remote and Spotify now worked within acceptable parameters, I wanted to show Volumio that I installed a few days ago to my wife tonight, but unfortunately it looked like it strangely went haywire, nothing plays any more, it shows an error messages about the soundcard “The selected output device is not available”. So I sure gave a terrible impression with this, after a few months of “messing” with Moode (which has a terrible bug that seems not possible to be solved). It does work normally with HiFiBerryOS (swapped for the time being, but I totally dislike this distro!). Hmmm... will look into this another moment. Wonder if that very last thing that I did with it has anything to do with this crash: volumio pull -b volatilePlay https://github.com/ashthespy/Volumio2 Actually I am not sure what it really does, which is not that smart of me to check out on the forehand, but it seemed to work great fixing that toggle thing.

Any help much appreciated!!

[ashthespy]

Actually I am not sure what it really does,

Never a good idea to copy paste stuff into the terminal without knowing what it does ;-)

Any help much appreciated!!

How were you using the REST API? Maybe it's easier to just re-flash Volumio to reduce debugging headaches?

[basmeyer]

Never a good idea to copy paste stuff into the terminal without knowing what it does ;-)

Indeed 😄 I did have a look now in the repository and filtered on volatileplay to learn a bit about it. It sure is good to have and to add in the next release, if possible, because it definitely fixed the toggle! But...

I got the https://www.hifiberry.com/shop/accessories/wireless-remote-control/ which works really well now, funny enough even with the play/pause toggle!!?? And so, without the command in the post above!

I did the following with the REST API's using Triggerhappy:

sudo apt-get install triggerhappy
sudo nano /etc/triggerhappy/triggers.d/audio.conf

Then in the editor I replaced the default with:

#VOLUMIO TRIGGERHAPPY CONFIGURATION FILE

#VOLUME UP
KEY_VOLUMEUP 1 curl "http://volumio.local:3000/api/v1/commands/?cmd=volume&volume=plus"
KEY_UP 1 curl "http://volumio.local:3000/api/v1/commands/?cmd=volume&volume=plus"

#VOLUME DOWN
KEY_VOLUMEDOWN 1 curl "http://volumio.local:3000/api/v1/commands/?cmd=volume&volume=minus"
KEY_DOWN 1 curl "http://volumio.local:3000/api/v1/commands/?cmd=volume&volume=minus"

#PLAY PAUSE TOGGLE
KEY_ENTER 1 curl "volumio.local:3000/api/v1/commands/?cmd=toggle"

#NEXT
KEY_RIGHT 1 curl "volumio.local:3000/api/v1/commands/?cmd=next"

#PREVIOUS
KEY_LEFT 1 curl "volumio.local:3000/api/v1/commands/?cmd=prev"

#STOP
KEY_ESC 1 curl "volumio.local:3000/api/v1/commands/?cmd=stop"

#CLEAR QUEUE
KEY_COMPOSE 1 curl "volumio.local:3000/api/v1/commands/?cmd=clear"

This is how I learned which buttons produce which keystrokes:

sudo thd --dump /dev/input/event0

So, < and > buttons are skipping songs, arrow up and down and the speaker buttons are volume control, = button is clearing the queue (if that would be handy to control by the remote, it was the assigned function that I could think of for now) and then the escape/returning arrow button is stop, after which the song is played from the beginning when you press OK again (which is the middel button and the play/pause toggle). Anyway, better leave it as it is for now and have the misses to spend some time with it and get familiar tomorrow. The remote is really nice and snappy, I cannot say this with in conjunction with HiFiBerryOS. Controlling that with their "own" remote is a pain. it does not respond to 4 out of 10 keystrokes, how illogical that may sound.

[basmeyer]

Update:

After a day and a half the remote control stopped working and I noticed I could not access Volumio through the web interface any more with volumio.local. I still can access it with the static IP that I gave it, strange enough this happened suddenly without any obvious reason. I have the feeling that Volumio also slowly died on me, it became more and more buggy/unstable where I did not expect this degree of buggy behaviour and I had to terminate and restart the web browser in order to gain proper control multiple times. But later I thought that this name resolving thing could perhaps have to do with it. Hope it stays a bit more solid for now.

I use a (brand new) 128 GB SanDisk SD. Could this be the problem? Flashed with balenaEtcher without any problems.

[ashthespy]

@basmeyer sorry to sound like a stuck record, but without logs we have no idea what is going on. Your issues sound like something completely unrelated to the REST API and or volspotconnect.. Most likely your dns resolver on your router isn't resolving volumio.local