Mapping keyboard forward/back/play buttons?

[wadewilliams]

My keyboard has buttons for previous/next track and play/pause.

These are super nice because I don't have to change context back to the spotify app to pause, etc.

Must have feature for me. Thank you for this!

edit: The buttons work if I have the full spotify application running, but using spotifyd and spotify-tui in tandem doesnt work. Please let me know if this issue is better addressed in spotifyd repo.

[Rigellute]

I also tend to have the full spotify client open so the media keys work. My intuition is that spotifyd should handle the media keys.

However, if it is easy for us to implement in spotify-tui than we could do it.

[luiswirth]

I think spotify-tui should be responsible for handling all key inputs, including the media keys. Spotifyd should remain just a music daemon for playing and nothing more.

[sputnick1124]

I'm inclined to agree with @LU15W1R7H, but this is more complicated than other normal key input. spotifyd does support this, apparently, but I have never gotten it to function correctly.

I know of no other way to handle the media keys in Linux than using the dbus/mpris method. While certainly more complicated than the rest of the app's key handling, I think adding support for mpris wouldn't be too terribly cumbersome.

If anybody knows of other ways to handle media keys, I'm all ears. Also, this would, to my knowledge, be a Linux-only (maybe Mac?) feature.

[Rigellute]

If spotifyd supports this (albeit experimental), I don't think spotify-tui should also attempt to implement it.

Given that the official client handles the media keys and spotifyd supports them, I feel it would complicate things greatly for spotify-tui to also support them.

[dzfranklin]

What if spt exposed the command line arguments --next, --prev, --toggle-paused, --volume-up, and --volume-down? They would ideally error if spotify-tui wasn't running, and if spotify-tui was running would have the same result as pressing the shortcuts in the TUI.

This would allow users to map their keys however worked best for them. Cursory Google search turn up relatively easy ways to bind a keyboard shortcut to a command on macOS, GNOME, and KDE. I use i3 and would be able to do this with a simple config file edit.

This would slightly decrease ease-of-use, but spotify-tui already requires equally complicated steps to authenticate. It would also let users have more control than the default Spotify client by allowing them to manipulate the Spotify volume (My use case: I listen to Spotify while playing videos, and sometimes the videos are quieter. I want to increase the video volume while decreasing the Spotify volume, so I can hear the video decently).

I don't think this would cause complications by duplicating functionality, at least in the sense that users wouldn't run into errors from both programs attempting to respond. spotifyd doesn't attempt to handle the media keys, it provides support for users to configure other software to handle the media keys (with difficulty).

I don't know how hard this would be to implement. I'm learning Rust right now, would you accept a PR? (I'm not certain I'd have the time to do it promptly).

[Rigellute]

@danielzfranklin interesting suggestion. This sounds doable, though somewhat tricky.

Feel free to take a stab at a PR.

However, I still think that this feature is better handled by spotifyd.

[ghost]

It's also possible to use xdotool to send keys to spotify-tui without much hassle.

Start spotify-tui with a known window classname: urxvt -name spotify-tui -e "spt"

Send commands to the window: Next song: xdotool key --window $(xdotool search --classname spotify-tui) n Prev song: xdotool key --window $(xdotool search --classname spotify-tui) p Pause/play: xdotool key --window $(xdotool search --classname spotify-tui) space

Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.

[Rigellute]

Very cool @xanderificnl! Thank you!

[freundTech]

Despite spotify and spotifyd already supporting mpris2 I think that having support for it in spotify-tui would be a good idea, as it would allow controlling remote spotify instances with mpris. In my case I have librespot (The library spotifyd is based on) running on my raspberry pi and use spotify-tui on my PC to control it.

Another alternative would be having a different spotify connect client, that only handles mpris. That's how I used to do it with mpd: Run the mpd daemon, which doesn't support mpris, a client without mpris and another client that only offered mpris.

[freundTech]

Ok. I quickly hacked a standalone MPRIS2 interface together in case anyone is interested. It's in python (I don't know enough rust) and still has a few bugs, but it's already more complete than the MPRIS2 interface built into the spotify linux client: https://github.com/freundTech/SpotPRIS2 You can install it using pip (pip install spotpris2) or if you are on arch from the aur (yay -S python-spotpris2)

[AndydeCleyre]

Adding, since I don't see it mentioned, that playerctl is an excellent utility that may be a good solution for some folks here.

For example, I have my DE set global keyboard shortcuts for the following commands:

playerctl -p spotify,ncspot,mopidy,spotifyd next
playerctl -p spotify,ncspot,mopidy,spotifyd play-pause

@danielzfranklin note that it also supports volume changes.

But I don't think it would help for those looking to control remote spotify clients, @freundTech . I haven't personally tested other tools that might help with that, but know of baton.

[jvinet]

If spotify-tui supported MPRIS directly, then I could use the media buttons on my laptop to control music playing from another Spotify device. spotifyd doesn't do this.

It's a minor use case, but super useful. :)

[fbrinker]

+1 :)

I mostly listen remotely with Alexa connected to the Speakers and right now i don't have any option to control the media player with my keyboard shortcuts (and playerctl) :)

Spotifyd works to get the metadata for my Polybar, but doesn't let me control remote devices.

Besides play, pause, stop, next, ... would volume keybindings be nice too

@ghost thanks for the workaround for the moment :)

[freundTech]

@jvinet @fbrinker https://github.com/freundTech/SpotPRIS2 let's you control Spotify, even remote instances, using mpris2 (and therefor using playerctl).

[fbrinker]

@freundTech nice, that works very well, using it with the --auto flag :) Will use it for now, thank you. I would prefer an all in one solution, but an interesting project :+1:

Edit: Okay spotpris is awesome, so i can use it to fetch the correct metadata and playing status for my polybar and remote control every spotify device now without any pgrep switches

[ConstantMan]

It's also possible to use xdotool to send keys to spotify-tui without much hassle.

Start spotify-tui with a known window classname: urxvt -name spotify-tui -e "spt"

Send commands to the window: Next song: xdotool key --window $(xdotool search --classname spotify-tui) n Prev song: xdotool key --window $(xdotool search --classname spotify-tui) p Pause/play: xdotool key --window $(xdotool search --classname spotify-tui) space

Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.

Hey I'm trying to use xdotoool with these commands but i can't figure out why it doesn't work any ideas ?

[tonglil]

I'm considering hacking on https://github.com/Sinono3/souvlaki as a standalone project to learn Rust so it can pull info from spt and use spt pb --next.