'volumio stop' CLI command works wrong with Tidal playing tracks

[phts]

When playing Tidal track and execute “stop” command, on UI it keeps ticking time, growing progress and showing “pause” button just like it is playing. Also “next”, “pause”, “previous” buttons became unresponsive, they do nothing. Only way to fix UI - open new track from library or queue.

In status: still “play” and “seek” is growing

However “stop” command works for local/nas files, in this case UI shows “play” button and time at 0 and not ticking as expected.

Seems like there is wrong behavior in statemachine file for music services.

Prerequisites

Volumio Information

Volumio Version: 3.429
Hardware: RPi
DAC:

Debug Log

info: CoreCommandRouter::volumioGetState
info:
---------------------------- Client requests Volumio stop
info: CoreCommandRouter::volumioStop
info: CoreStateMachine::stop
info: CoreStateMachine::setConsumeUpdateService undefined
info: CoreStateMachine::stPlaybackTimer
info: CoreStateMachine::updateTrackBlock
info: CorePlayQueue::getTrackBlock
info: CoreStateMachine::pushState
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , saveDeviceInfo
info: CoreCommandRouter::volumioPushState
info: CoreStateMachine::serviceStop
info: CorePlayQueue::getTrack 0
info: CoreCommandRouter::serviceStop
info: [1677069344963] ControllerTidal::stop
info: CoreStateMachine::setConsumeUpdateService mpd
info: ControllerMpd::stop

info: [GPIO_Control] *** musicStop ***
info: [GPIO_Control] Delaying: 0ms
info: [GPIO_Control] Turning GPIO 4 Off (musicStop)
info:
---------------------------- MPD announces state update: player
info: sendMpdCommand stop took 76 milliseconds
info: ControllerMpd::getState

info: sendMpdCommand status took 4 milliseconds


info: sendMpdCommand playlistinfo took 4 milliseconds

info: ControllerMpd::pushState
info: CoreCommandRouter::servicePushState
info: CoreStateMachine::pushState
info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , saveDeviceInfo
info: CoreCommandRouter::volumioPushState
info: CorePlayQueue::getTrack 0


info: CoreStateMachine::syncState   stateService stop
info: CoreStateMachine::syncState   currentStatus stop
info: CoreStateMachine::pushState
info: CoreCommandRouter::volumioPushState
info: No code
info: CoreStateMachine::pushState
info: CoreCommandRouter::volumioPushState
info: ------------------------------ 100ms
info: [GPIO_Control] *** musicPlay ***
info: [GPIO_Control] Delaying: 0ms
info: [GPIO_Control] *** musicPlay ***
info: [GPIO_Control] Delaying: 0ms
info: [GPIO_Control] *** musicPlay ***
info: [GPIO_Control] Delaying: 0ms
info: touch_display: Setting screensaver timeout to 0 seconds.
info: [GPIO_Control] Turning GPIO 4 On (musicPlay)
info: touch_display: Setting screensaver timeout to 0 seconds.

info: CoreCommandRouter::volumioGetState

Steps to Reproduce

1. Play Tidal track
2. Run volumio stop CLI command

Additional Information

[Wheaten]

If I recall correct for Tidal there is no stop, but Play/Pause or toggle.

[phts]

yes, but “stop” is common CLI command and should be handled properly anyways, or explicitly disabled for Tidal (e.g. throw error, etc)

On service level it should mock “stop” action and for example duplicate “pause” behavior, or any reasonable logic which avoid having this bug in UI.

As a consumer I cannot know that I dont have to use “stop” only for tidal.

[Wheaten]

I believe stop was only used with radio streams, as they can’t be paused.

[phts]

and for local or nas files as fas as I tested

[phts]

In this case please update docs to explicitly say, that “stop” is supported only for radio, and other services are not supported officially.

[Wheaten]

Also the Volumio UI uses play/pause or toggle for NAS files.

Only the webradio will do a stop:

[phts]

Well, UI is not source of truth what supported or not.

Talking about CLI and websocket API.

And BTW, in the example on WebSocket APIs - Volumio Documentation there is “stop” status for NAS file So your example with UI usage is not relevant for this topic.

So from docs it is unclear when to use “stop”.

So at least please add info, e.g. “stop” is used only for radio.

Perfectly would be nice to add support for “stop” to be transparent for consumers in all cases, service should decide if it supports it or not, instead of user. Or throw errors and check if current service is not “webradio” then throw error.

[Wheaten]

I am just a forum moderator trying to get you going, not to start discussions.

[phts]

Quick workaround - fix: "stop" support for tidal · phts/NP-01_volumio3-backend@12b5ab2 · GitHub

(I didn’t create pull request, because this fix is very specific for my needs, you probably would want more generic solution)