starred/spotify-tui

Fork 0

mirror of https://github.com/Rigellute/spotify-tui.git synced 2026-04-26 16:15:55 +03:00

[GH-ISSUE #214] Add reset track control #106

New issue

Closed

opened 2026-02-28 14:47:05 +03:00 by kerem · 8 comments

kerem commented

2026-02-28 14:47:05 +03:00

Owner

Originally created by @amgassert on GitHub (Jan 18, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/214

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.

Originally created by @amgassert on GitHub (Jan 18, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/214 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.

kerem closed this issue

2026-02-28 14:47:05 +03:00

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Jan 22, 2020):

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.

@sputnick1124 commented on GitHub (Jan 22, 2020): 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](https://github.com/ramsayleung/rspotify/blob/master/src/spotify/client.rs#L1640-L1650)), which should correspond to clicking the "Previous" ![image](https://user-images.githubusercontent.com/8843309/72933427-ba811380-3d2f-11ea-9157-83ddd328e1c0.png) button in Spotify's native GUI application.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@amgassert commented on GitHub (Jan 23, 2020):

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.

@amgassert commented on GitHub (Jan 23, 2020): >`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](https://developer.spotify.com/web-api/skip-users-playback-to-previous-track/)), you'll find the following line: >Note that this will ALWAYS skip to the previous track, regardless of the current track’s progress.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Jan 23, 2020):

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.

@sputnick1124 commented on GitHub (Jan 23, 2020): Ah! you're right. Seems I was still looking at the [beta API documentation](https://developer.spotify.com/documentation/web-api/reference-beta/#endpoint-skip-users-playback-to-previous-track) 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.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@amgassert commented on GitHub (Jan 23, 2020):

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.

@amgassert commented on GitHub (Jan 23, 2020): 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.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Jan 23, 2020):

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 commented on GitHub (Jan 23, 2020): 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.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Jan 23, 2020):

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.

@sputnick1124 commented on GitHub (Jan 23, 2020): 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.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@amgassert commented on GitHub (Jan 23, 2020):

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.

@amgassert commented on GitHub (Jan 23, 2020): > 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.

kerem commented

2026-02-28 14:47:06 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Jan 23, 2020):

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.

@sputnick1124 commented on GitHub (Jan 23, 2020): > 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.