Using API previous track call, just restart current song.

[Ejay-3D]

Alos raised to raspotify repo as it is the player I used . But I don't know if the issue is in librespot or raspotify code.

dtcooper/raspotify#188

I'm using the following spotify API
https://developer.spotify.com/documentation/web-api/reference/player/skip-users-playback-to-previous-track/

If you are running raspotify and try this API from here:
https://developer.spotify.com/console/post-previous/

you will see that it put the current song back to the beginning and not to the previous one.
If you try the same with a web player or if the song is played on a phone.
When you run the API it doesn't well call the previous track.

Could you please investigate?

Thank you

[StopMotionCuber]

I'm not entirely sure what you mean, but I'm guessing your steps to reproduce:

1. Play a couple of songs songs (min: 2) in shuffle on Desktop
2. Switch Playback device to Librespot/Raspotify client
3. Press "previous song" (or do an API call)

The problem here is, that in step 2 the context is getting lost so everything is newly shuffled and the currently playing song is the first song.

Does this describe your issue or do you mean something else?

[Ejay-3D]

Yes it seems correct. As you explained the issue is like there's no previous song to play. So the current song just restart from begining. But I'm playing several track on raspotify device. Even Playlist. So the context should be here. If I use another player (web player) I'm able to play the previous song with the same api call. Only raspotify doesn't jump to previous track. It just restart the current one.

[Schluggi]

I've an similar issue using badaix/snapcast witch is also using librespot.

I hope this can help to explain the issue:

[sashahilton00]

@Schluggi it's been a while since we implemented the shuffle functionality, and I'm on mobile so can't check, but I believe we shuffle the songs in the queue, i.e. the songs after the currently playing one, hence pressing the shuffle button multiple times doesn't cause a new track to start playing. Though given the official client does this, it might be worth investigating adding this behaviour to librespot.

[kingosticks]

I'm confused by this issue, can we first confirm what we are talking about?

The original OP doesn't mention shuffle and their link is very specifically about skipping back to the previous track regardless of the current track’s progress - which we do not support. When we get a previous command we skip back to the previous track only when we have played more than 3 seconds of the song; otherwise we skip back to the start of the current song.

If this is indeed shuffle related then this is a duplicate of #264 and the recent context resolving work may allow us to fix it.

Pressing Spotify's "shuffle play" button multiple times (if that's what that animation shows, I really cannot tell) and not having it play every time does not sound like the same thing to me and belongs in a separate issue.

[Schluggi]

@sashahilton00 I'm relay sure, that this was working for me until round about December 2018.

@kingosticks I've misunderstands the issue. Sorry for that but #264 doesn't seems to be my issue.

[sashahilton00]

@Schluggi ok, good to know. Please open a new issue though, as this one is for an apparent bug with API control.

[Ejay-3D]

It is not an issue with shuffle but with Previous API .
I have create a 50 seconds video to demonstrate the issue .
I hope that will clarify for everyone .

Ejay
raspotifyAPI.zip

[maxx]

I've also been seeing this exact issue (restart current song on new song selection) for the past couple of weeks. This happens regardless if shuffle is on or off, so I believe it's an unrelated issue.

Only workaround is to disconnect (play on local client), select the new song, and then re-cast to librespot.

[sashahilton00]

@ejay-ibm based on your video, the client is behaving as expected. You initially fire the API request when 0.17 seconds of the track has played, and it restarts, then you try again once 0.07 seconds of the track have played. Librespot will only go to the previous track if you have played 0.03 seconds of the track or less. Assuming 0.5-1.0 seconds for the api request to be relayed to librespot, you probably need to fire the API call within 2 seconds of the track starting. Realistically, calling the API twice, by double clicking the send request button, should cause the previous track to play. Granted, it's not ideal UX wise, but if that does indeed work, then we can look at potentially discriminating between requests from the desktop client and the Web API and handling the previous track requests slightly differently.

[Schluggi]

@sashahilton00 It's embarrassing to me to say that my issue was obviously fixed in the current version of librespot. Again sorry for the inconvenience.

@maxx Updating librespot should fix it. If not please open a new issue for that.

See you!

[maxx]

oops..I should have tried current master before posting as well. thanks everyone :)

[Ejay-3D]

@maxx This git is not about shuflle but previous API . please stay focus on the Git Title
Using API previous track call, just restart current song.
That will allow less confusion, thank you for your understanding.

@sashahilton00 thank you for your update.

you are saying: Librespot will only go to the previous track if you have played 0.03 seconds of the track or less. That is what create the issue indeed.
Thanks for clarifying that .

Is there a way to increase this value in your code?

Else the only workaroud would be 4 api call to call a previous song at anytime ( which is pretty heavy )
Pause - Seek to 0 - previous ( that should work since we are at 0 - then restart the play .

Let me know if you can enhance this in libresptot, or if I should workaround this because code will not change.

thank you again

[maxx]

@ejay-ibm I was specifically calling out that this was unrelated to shuffle (just as you are)!

regardless, trying current master branch tonight and will report back.

[sashahilton00]

@ejay-ibm sorry, i jsut realised my phrasing above is terrible. Read all the numbers in code snippets as you would in the spotify client (i.e. 0.03 is 3 seconds). I've just had a look at the API, and can confirm that mashing the send request button 2-3 times does cause it to jump back 2 songs, so it does work, but the experience isn't great as you noted.

Additionally, there seems to be a slight bugginess, in that spamming the previous track request causes the prior song to fail to load (on macOS), with the error ERROR:librespot_playback::player: sink error: portaudio error: Output underflowed. Skipping back to the song before the prior song works fine, but then going to the next song, either via the official clients or the API causes librespot to skip every other song.

I'm going to mark this as a feature enhancement request; there is something wierd going on with portaudio, which could be construed as buggy behaviour, but I have yet to determine whether this affects everyone, or just me. Secondly, within the next couple of days, rodio is going to become the default playback backend, which may alleviate the issue. Hence, unless this is confirmed by others as being a universal bug (w/ regards to portaudio), I'm assuming it is my machine. If someone else with a mac could test, that'd be helpful.

EDIT: Just tried with rodio backend, didn't see the buggy behaviour outlined above.

@ejay-ibm not sure what you're using the webapi in, but the following pseudocode should illustrate how to deal with skipping to previous track:

function previousTrack() {
  if (player.playing.current_position_ms > 3000) {
    //Trigger previous track API request
  }
  //Trigger previous track API request
}

[Ejay-3D]

@sashahilton00 Thank you , May I ask you to change the 3000 value to maybe 10000 ?
So I can implement the following in my code:

previous(cb) {
    this.doRequest("/v1/me/player/seek", "PUT", null, {position_ms:0}, cb // so i'm going to position0 
    this.doRequest("/v1/me/player/previous", "POST", null, null, null) // then I call the previous API . 
)
  }

The thing is 3 seconds is too short to make the seek 0 call then the previous call .
It look like the API take more than 3 seconds to reply . so when calling previous song is already at more than 3 seconds .

So with an higher value we should be good.

It is feasible?

Thank you

[sashahilton00]

@ejay-ibm we're not going to change the value from 3000; this is the value set in the official client. We may add code to descriminate between commands from native clients and the web API, I'd entertain a PR for that. Also, you shouldn't need to seek and then call the previous endpoint. Just fire 2 requests simultaneously to the previous endpoint if more than 3000 ms of the track has played, otherwise only fire 1 request.

[Ejay-3D]

Ok will give this a try .
thanks

[sashahilton00]

Note to self (or future implementer): Only difference between native client and webapi calls appears to be a call to hm://remote/3/user/USER/webapi-774b...dad9c86, hence a stringmatch on webapi ought to do the trick.

EDIT: The above is the bad and lazy way to do it. player_context_state appears to contain the necessary fields to determine whether to go to previous track or restart current.

[StopMotionCuber]

Related to this issue i found out this morning that scrolling back in cover view from the Android App has the same behavior. Here I'd expect the previous song to start, as opposed to the "prev Song" button where this behavior is expected.

[sashahilton00]

This behaviour is handled in the context_state json payload. We need t odo further reverse enginnering and work on that for proper implementation.