See:

- https://medium.com/@b3ngr33ni3r/hijacking-spotify-web-contro...

- http://cgbystrom.com/articles/deconstructing-spotifys-builti...

- https://code.google.com/p/spotify-local-api/

Thanks

Gotta love that.

Sorry :(

I had to downgrade to 0.9.15.27. If anyone wants to do the same here are Windows instructions:

- Uninstall current Spotify

- Grab the old version and install it: http://www.filehorse.com/download-spotify/old-versions

- Stop Sptofiy from auto updating create 2 read-only files (blank txt for example) named 'Spotify_new' and 'Spotify_new.exe.sig' in C:\Users\<User>\AppData\Roaming\Spotify

I tried switching to Spotify but had a hard time moving playlists. More than half my songs were not found on Spotify.

Seems like a very common scenario they don't support any longer, for technical reasons? for not wanting people to listen to music that way?

You guys are great. From a UX standpoint, I get what you're going for. As a marketer, it makes sense. And as a developer, I can honestly say 1.0.2.6 wouldn't come CLOSE to qualifying as a gold master, let alone something you pushed out to millions of people.

The "bugs":

1) Rendering. Composite views in the app take 1-2s to render on an 8-core Xeon and a T1 line--I've seen much better performance from React which is DOM-based, so what gives? Are you firing synchronous API calls before loading the resources??

2) Local Files. More below under "personal grievances," but I consider this a bug for two reasons: first, you cannot sort by date added or adjust columns in any meaningful way. Second, it's not scanning local directories properly because plenty of local music found in "Songs" is missing from this view.

3) Hover states. Dear god, hover states. If you actually are coding this native, then you've got something weird going on with your first responder, layering, or a timer somewhere because drag selection states are buggy everywhere. Songs, playlists, and starred. Play around with this and you'll notice how something keeps interrupting the current layer event.

4) Play bar. I don't know if you changed the protocol on the local server responsible for actually streaming, or if you shifted over to some event/dispatch structure, but I'm getting a 1s delay and surprising lag on the play bar. Not exactly sure of the culprit, but it makes it very difficult to quickly drag and scan. To clarify again--this is not related to the network. Probably related to buffers and however current_position is reconciled.

5) Spotify Helper. Did I mention it's eating up 100% CPU on one core consistently? Whatever you're doing on the rendering side with bindings is foobar. I get this 50% of the time launching the app. Yes, I've run disk utility, verified and repaired permissions and the primary sector. And my RAM (and VRAM) is fine.

https://gist.github.com/j42/e11c0a2f5ee4d288cb31

6) A little one. When creating a new playlist and the artist + album fields are all uniform, it should auto-populate the playlist title. Not a big deal, but worth noting.

On to the "personal gripes," or "dark patterns." I get why you're doing it, but I don't like it:

1) You can't hide the social bar. I realize you want people to use the feature, but why not turn it on by default and still LEAVE the option to hide it in the 'advanced' section of preferences most people never visit anyway?

2) Local files are treated as second rate. Worse still, as mentioned above the local files view is actually broken. But even going through search and songs, trying to work with any kind of local media has become a pain in the ass.

For what it's worth, the API seems very well designed and as a whole the ecosystem has traditionally worked quite well. Especially when handing off streams between multiple devices and/or protocols.

I'll stick with my subscription for the time being, but can someone with actual clout take these issues seriously rather than just echoing the same old "we'll notify the devs, thanks for your suggestion!"

It's all HTML and JS under the hood, each "app"(artists, playlist, etc.) differs in their stack - but web technologies. All wrapped up in CEF: http://en.wikipedia.org/wiki/Chromium_Embedded_Framework

There is even an ongoing list of core functionality which is now broken in the client: https://gist.github.com/TobiasBerg/350a06131d41d2996098

Bonus: try dragging a local file(any extension) into your Spotify client - and yes a HTML file with JS will render(hello alert())

Those composite views have lots of assets. A second or two seems reasonable over a 1.5 Mbit/s connection. (Unless I am thinking of another view than the one you mean.)

To expound on the other reply, he's probably right. My guess is they made a major push to refactor/simplify the codebase and in an effort to remain 'stateful' they shifted the balance a little bit too far toward the network over local caches and stores. Even still it could work, as long as you can properly pre-render the last-synced state and decouple any view elements from the synchronicity of the actual data streams and JSON metadata. The version prior did this perfectly.

Anyway my hope is a lot of this will be fixed in the near future and with any luck the dev outreach will improve--IMHO that's the only area they have really been consistently lacking.

I use the free version, and while I noticed it is a bit different since a few weeks, didn't really notice anything that would bother me.

It also removed the 'search' (command + F) in the song list.

I could see them not wanting to support poorly created apps, but removing the last one boggles my mind.

edit: I am talking about the search in playlist (command + F)

Removed ability to minimize to tray

Removed adjustable width of columns

Removed tons of settings like how much space to allow the client to cache

- The titlebar always says Spotify Premium (or Spotify Free). Because that's super useful to people.</s>

  SetTitleMatchMode 2
  IfWinExist,Spotify Premium
  {
    WinActivate
    sleep, 100
    send, {space}
  }
  SetTitleMatchMode 1

    F6::Media_Prev
    F7::Media_Play_Pause
    F8::Media_Next

Looks like you might have to just use good ol' reverse engineering...

(As an aside, I'm amazed Spotify doesn't provide an API for this.)

In which case, the Spotify engineer would simply not respond. The Spotify engineer is going to be far more aware of corporate culture than the outsider who can't get any info out of them.

Let's not shame people for openly asking questions when they've already tried to solve the problems themselves and also failed when using the 'official' channels.

Second, it's naive to think Spotify engineers are, as a class, immune to the sort of social engineering that would lead people to commit serious policy breaches. If people can be tricked into giving away their social security numbers over the phone, it's not unreasonable to imagine somebody not realizing something was serious that actually (for whatever reason) was.

I understand that you don't intend to be shaming, however that's what you're doing: "how can you ask this question, when it might cost someone their job?". We can't all walk on eggshells in order to protect those people who are close enough to the technical core to give technical answers, yet naive enough to not be aware of phishing and/or draconian corporate culture.

In short, ask away. If there is a draconian response as a result of your questions, that onus is not on you. And it's not like other phishers will leave that naive person alone simply because you did; they're still going to be a weak link in the chain, and they'll get compromised by someone malicious, and they'll still lose their job next time around while at the same time exposing their company to a malicious actor.

Similarly, if we're talking theoretical situations, then how about Spotify management not being jack-booted thugs[1], and when the data breach is found, instead of firing the naif, they use the event to update their corporate policies and retrain all employees with access to privileged information about phishing threats, thereby strengthening the company against future malicious attacks? The naive employee then gains some valuable information on the nature of the world and the company ends up stronger after this benign 'scare'. Win-win all around.

[1] I don't actually know what kind of footwear they use

If an hypothetical engineer gets fired for revealing IP, then the onus is on the engineer to not reveal IP. Not on OP for asking help.

This whole idea of not asking someone a question in case they would answer and be put in some Kafkaesque corporate politics nightmare sounds insane to me. How is this scenario what comes first to your mind?

You are welcome to think my company is just dysfunctional but I think it's a reasonable enough concern to at least be worth bearing in mind -- and the OP responded to my post agreeing with that sentiment.

It's a bit naive to simply say "the onus is on the engineer", as if no engineer could be tricked by social engineering into seriously breaching policy.

The onus is certainly on the engineer to distinguish between information they can divulge and that which they would need clearance for. You can't ask the good guy to not ask questions by stating that questions are what bad guys use to trick by social engineering.

Your argument is inverting the burden of responsibility. It's not OPs job to protect your IP, it's yours. You can't ask them to not ask any questions in case that a questionee was in possession of IP and susceptible to social engineering.

But the Last.fm plugin no longer works: https://open.spotify.com/app/lastfm

http://i.imgur.com/nPoKDOR.png