Add reset track control

[amgassert]

It would be nice if there were a way to reset the track (seek to 0:00). Going to the previous track (p) then next track (n) to reset the song isn't ideal because it requires an extra keypress, and the previous song immediately starts playing.

[sputnick1124]

This is already the behavior of pressing p. p only backs up to the previous track when playback is at the beginning of the current track. Essentially, rspotify simply sends a request to the "/player/previous" endpoint (see here), which should correspond to clicking the "Previous" button in Spotify's native GUI application.

[amgassert]

p only backs up to the previous track when playback is at the beginning of the current track.

This is not true.

Essentially, rspotify simply sends a request to the "/player/previous" endpoint...

If you take a look at the documentation for that endpoint (see here), you'll find the following line:

Note that this will ALWAYS skip to the previous track, regardless of the current track’s progress.

[sputnick1124]

Ah! you're right. Seems I was still looking at the beta API documentation still where that is not called out.

That said, I have not noticed that this behavior has actually come about yet, but I agree that this should be addressed and your PR looks good to me.

[amgassert]

Which version are you using? I'm experiencing this behavior with v0.11.0.

We might also consider changing the behavior of the p button to use the seek endpoint, as the official client does with its previous button. I think some people may prefer this to the changes I've proposed in #215.

[sputnick1124]

I am also on 0.11.0. Besides, this would be agnostic to the version of spt since this on Spotify's end, no?

Also, +1 to your point of handling this within spt with only the p binding. Having an additional keybinding would be an unexpected necessity.

As for Spotify's API documentation, it is very confusing which to believe. The endpoint you have referenced is marked beta and there is a link at the top of that page which takes you to the docs I referenced, which are also beta. At any rate, even when I click the "TRY IT" button on the endpoint's doc page, it still only resets playback.

[sputnick1124]

Ah, just figured it out right after posting. I am using spotifyd as my Spotify Connect device, which has shown some abnormalities in other cases. This must be another one of those cases.

When I play spotify through the native app, the endpoint behaves as documented.

[amgassert]

I am also on 0.11.0. Besides, this would be agnostic to the version of spt since this on Spotify's end, no?

I assumed previous versions of spt might use a different version of rspotify, which may use the endpoints a bit differently, but it looks like the last several versions all use v0.7.0 of rspotify. Also, if this were entirely on Spotify's end, wouldn't we be experiencing the same behavior?

Also, +1 to your point of handling this within spt with only the p binding.

I'll get started on this tonight then.

[sputnick1124]

if this were entirely on Spotify's end, wouldn't we be experiencing the same behavior?

I would have thought so, but this is obviously not the case. It does make some sense that the difference would not lie in the spt client but rather the spotifyd server, though. The root of the discrepancy lies within librespot (which is what spotifyd is based around). That is the library which implements the Spotify Connect protocol and allows the service to show up as a Connect device. Since this has been reverse engineered, there are bound to be some implementation errata.