[1.0.17.75] DBus interface is not working properly

[actionless]

after update from 0.9 i noticed what there are no any dbus endpoints provided by app and no any signals sent on any activities.

is that sorta bug or one more removed feature?

UPD:

Now it's possible to control playback status and get current track metadata.

But Spotify still don't send dbus signal on status change (like next track and so on) and it's not possible to get current playback status.

[skruttenhehe]

I wonder this as well. I can't find any dbus associated with Spotify at all. Is there any way to get some sort of confirmation on if this has been removed or not?

I am running version 1.0.1.1062.gaa7a606c.

[browo]

is there any alternative to sending media keys to spotify to replace the dbus functionality?

[abenjami]

It looks like the DBUS service is no longer there. Can we please have it back?

Thanks.

  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.mpris.MediaPlayer2.spotify was not provided by any .service files

[Q-tip]

+1 for reinstating DBus. I have a cron script which starts Spotify to wake me up in the morning and gradually increase the volume. This system has been working for me for the past year and a half until now. Luckily, I set a backup alarm just in case or I would have been REALLY late to work.

I'm also kinda missing the menu bar and playlist dividers (playlists named "-") but I guess those are off topic for this thread.

[Dzarda]

Yeah, unfortunately I have to confirm this.

It's missing in version 1.0.7.153.gb9e8174a

DBus shows no services related to Spotify.

Devs, please, put it back in, it was a good feature!

[ibbles]

There are some alternative ways of controlling Spotify listed here[1]. So far I've only tested the xdotool way, but without any success.

[1]: https://wiki.archlinux.org/index.php/Spotify#Global_media_hotkeys

[chrisb2244]

Also having no success with xdotool (possibly because of the window targetting?). Wish DBus interface was available.

[black3r]

Spotify seems to have a running web-server that accepts JSON structured commands and there seems to exist a client for this interface written in node.js for windows https://www.npmjs.com/package/node-spotify-webhelper . With a little tweaks to this (spotify does not use https on my linux machine) i am currently using solution based on this as an alternative to media keys. Problem is it's kinda slow. Sending a play/pause command takes about 2-3 seconds 😞

[Dzarda]

I kind of think that the QtDBus dependency was removed due to binary-size reduction taking place during development. It simply might not be used in-app anymore.

[ibbles]

The web server commands work here as well, after some https tweaking as you said.

I'm more of a Python than JavaScript guy so I'm using Carl Byströms implementation outlined at http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/ and available at https://github.com/cgbystrom/spotify-local-http-api.

The reason for the slowness in that implementation is that it goes and gets a new pair of authentication tokens every time it is run.

I fixed the slowness by adding a socket read loop around the play/pause/etc calls. I then bind the media keys to commands such as

  echo "play" | telnet 127.0.0.1 34128

which work instantaneous.

However, I have not been able to find a list of available commands to send and none of the examples I've found include changing track/song. Only open/play/pause/status.

Cannot find anything useful at https://developer.spotify.com/web-api/.

Anyone knows?

[chrisb2244]

---

@ibbles wrote:

The web server commands work here as well, after some https tweaking as you said.

 Could you detail the changes? I tried changing all (both) occurences of 'https:' to 'http:' but I'm still hitting an error with the python script:

Traceback (most recent call last):
  File "http_remote.py", line 93, in <module>
    csrf_token = get_csrf_token()
  File "http_remote.py", line 51, in get_csrf_token
    return get_json(get_url('/simplecsrf/token.json'), headers=ORIGIN_HEADER)['token']
  File "http_remote.py", line 27, in get_json
    return json.loads(urllib2.urlopen(request).read())
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 431, in open
    response = self._open(req, data)
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 449, in _open
    '_open', req)
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 409, in _call_chain
    result = func(*args)
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 1227, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/opt/Python/Python-2.7.9-64/lib/python2.7/urllib2.py", line 1197, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 111] Connection refused>

I'm not really a python guy, so I don't know what this is all trying to do - running the script provided on the github site line by line indicates the error comes in the `return` statement of the `get_crsf_token` function. (Or method, maybe... I'm not sure re Python). `print (url)` and `print(request)` both return things that look sensible within the function, but `json.loads(urllib2.urlopen(request).read())` throws that 'Connection refused' error.

[chrisb2244]

Richraid21's spoticli works for me - it is a fork (possibly of another fork) of the python implementation for which a previous link was posted.

Now just to figure a way to pass arguments sensibly, and implement 'skip'

[chrisb2244]

Forked Richraid21's implementation, now have command line arguments accepted. Still need to implement skipping.

Have inherited ssl verification problem from the forked repository - probably will make no effort to fix this since I don't know what's wrong, or how to interpret python, but my assumption is that the default CA-certificates make no allowance for *.spotilocal.com, or perhaps some 'localhost' style authentication. If anyone knows how to fix this, feel free to make (another) fork, or file an issue with patch or pull request, etc.

My fork: spoticli - chrisb2244

[chrisb2244]

---

@ibbles wrote:

Cannot find anything useful at https://developer.spotify.com/web-api/.

Anyone knows?

---

So after also not getting anywhere with the web-api you linked to, or with various google searches, I opened an issue on the github issue-tracker for the web-api.

It has just been closed, with a nice explanation from (one of?) the developer(s?) - the web api can't (or at least, isn't designed to) do this skipping forwards/backwards on a playlist.

Back to the drawing board!

Issue response pasted below, for those interested to read, but insufficiently to find 🙂

JMPerez:

What you are trying to do is managing the current queue / playback on your desktop client from a web app.

The Web API doesn't expose endpoints to do it, that's why you can't find it. The linked examples, like Thirtify use the 30 seconds audio previews for the playback, which happens on your browser and it's independent from what you are playing on your Spotify clients.

Spotify doesn't provide any official way to control the playback in the client from outside through HTTP calls, and even though there are some back-engineered implementations out there, they are not officially supported.

[warthogdj]

I have to agree that these release logs are kind of small.

Also i am asking myself why remove Dbus form the program, so there is no Api left, no CLI

The client is now running multiple instances of itself.

So it is kind of useless. I only use spotify since few years now, just realized that this was a really bad thing, i may gonna switch to another player like Clementine which integrates like standard features (works in windows/Linux/Osx), but also a spotify plugin.

So i would listen music from other sources and eventually cut off my spotify subscription by using other services.

All of this because the player is such bad, and every effort is put on the visual, which is tiring me.

Wrong thread answer, but removing dBus support sucks !!!!

[ibbles]

It has just been closed, with a nice explanation from (one of?) the developer(s?) - the web api can't (or at least, isn't designed to) do this skipping forwards/backwards on a playlist.
 
Back to the drawing board!

So that's it? The only way to chage track is to Alt+Tab through possibly dozens of windows to find Spotify, change the track and then Alt+Tab back again, messing up the window history in the process. Doesn't seem right.

[Q-tip]

the web api can't (or at least, isn't designed to) do this skipping forwards/backwards on a playlist.

This was a hack anyway. If we could just get the DBus interface back, we wouldn't have to mess with the web interface.

[chrisb2244]

Problem is solved in the 1.0.13.112 release for Linux. See the release thread.

Dbus now present again.

Spotify can be controlled using the sp utility (a bash script using dbus).

I have not tested that particular link's version, instead using Nikreiman's fork.

The fork works for me, and allows use cases such as 

• sp next
• sp pause
• sp play

I can then bind that executable with an argument to a hotkey, allowing 'global' keyboard control of the skip key.

Yay!!

[actionless]

Cool to see it back again.
But now when track/playbackstatus changed there is know any message send on dbus about it (except of notification, but that's another story).
And all the endpoints are here again but still some of them not function correct -- at least PlaybackStatus and CanPlay are not returning any result now. I tested PlayPause, Metadata and prev/next and they're working fine though.