Hacker News new | comments | ask | show | jobs | submit login
Ask HN: I'm looking for a Spotify software engineer to speak to
84 points by azeirah on Mar 23, 2015 | hide | past | web | favorite | 57 comments
Hey HN, I'm the author of a popular music plugin for streamers, http://sourceforge.net/projects/obsmusicstreamd/

My plugin takes the current playing song from several music players, and outputs it to a text file, so it can be shown on a stream. Spotify's most recent update broke compatibility with the plugin however, and now I'm being flooded with emails :(

Previously, it looked through all Windows using the win32api, and looked for windows with "Spotify - " in their title. Spotify's most recent update replaced the title with "Spotify Premium" however. And now I'm at a loss, I've tried contacting their support to connect me to an engineer, but they didn't want to.

I've looked through Spotify's Appdata/local and Appdata/roaming folders, but found nothing I could potentially scrape to get the currently playing song.

So now, I'm looking for either someone with a lot of experience with Spotify who can help me out, or a Spotify engineer with inside knowledge...




If I remember correctly, the Spotify app creates a local web server with an API that can be used to grab the currently playing song, among many other things.

See:

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

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

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


I'm definitely taking a look at these, they look very promising.

Thanks


Best case scenario just happened.

Gotta love that.


Spotify's most recent update has ruined a lot of things for a lot of people - you're not alone. I've had repeated conversations with Spotify Support about the various things the update destroys, and they have made it clear they will not escalate any requests in a way that involves letting me (or anyone, presumably) speak with an actaul developer - though they will say they've "forward[ed] your ideas to the dev team" if you complain enough.

Sorry :(


I am still amazed how they pushed out this "update" to millions of customers. It removes so many key features.

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


Yeah, similar frustrating experiences here led me to cancel my spotify premium subscription today and try Google play music, which apparently has all but one of the albums I regularly listen to. Normally that'd bother me but Google lets you upload your own songs and they're treated like first class songs, so I'm super happy with my choice.


Caveat emptor. There's no native desktop apps for Google Music, nor do they have an API for future integrations. On OS X, give Radiant Player a try.

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


I'm sure the support agents you've been speaking to are just saying what they've been asked to say. Let's not kill the messenger here. This is likely a decision that is way above theirs and most of their developers' pay grades unfortunately.


Oh, yes, absolutely, and I treat them with politeness. However, the fact there's no transparent procedure to escalate to anywhere above the regular support staff (even to a support supervisor) is indicative of Spotify's overall disinterest in caring for its customers.


That you no longer can sort by popularity AFAIK any longer is mindboggling, although even before you had to know about the "spotify:search: syntax.

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?


I really, really hope at least one of their devs reads HN.

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!"


> 1) Rendering. > 3) Hover states.

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())


> Composite views in the app take 1-2s to render on an 8-core Xeon and a T1 line

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.)


Sorry, that was a slip up on my part :). It's actually a 150Mbit/s line, and I usually get ~20MB/s solid throughput downstream (megabytes) hence the weirdness.

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 assume "composite views" -> "playlists." I have a 3,200 song playlist that takes 5-10 seconds to load, whereas it was <1 second prior to the latest update. Maybe it was caching a local copy and now it always pulls from the server?


Just curious - what has it ruined?

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.


They removed support for 3rd party apps. This devastated me as it was the best music discovery service I've found (KCRW Music Mine and Pitchfork in particular).

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.


At first I thought my spotify was strange, because I was trying to look in my playlist and a few minutes of searching today I discover they removed that feature in the new version and right now the only way to get it back is to download and old version, my questions is why did they have to remove this, and they have done this in other times.

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


The lack of command + F frustrates me roughly 15 times a day.


Few more that ticked me off other than what is already mentioned:

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


- Ability to specify WHERE to cache files. This matters, because I have drives for data on my workstations, and partitions for data that're reachable in an OS-agnostic way on my laptop. I doubt I'm the only one who wants to cache music on a drive other than the SSD system drive.

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


The autohotkey script that pops up when you google "spotify autohotkey" broke, and that pretty much prevented me from listening at work for a week. Very annoying to not have a quick way to stop my music when a coworker taps me on the shoulder.


I've since downgraded, but for the day where I was using the new version I had to switch to something more clunky:

  SetTitleMatchMode 2
  IfWinExist,Spotify Premium
  {
    WinActivate
    sleep, 100
    send, {space}
  }
  SetTitleMatchMode 1
And alt-tab may also help, but it sometimes brings up the wrong window.


I noticed this too. It works if you map to the `Media_*` keys, e.g.

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


Just buy a Mac - there's a play/pause button on the keyboard!


Why not use Spotify with a third-party player like Clementine? (Although maybe that's not allowed for free subscriptions?)


I just discovered Clementine and was quite excited that it would let me play Spotify, but it keeps stopping part way through a track and skipping to the next.


Yeah, that does happen to me too occasionally, and I'm not sure why. I wonder if it's Clementine's fault or the binary blob.


Have you considered the possibility that someone could get fired for helping you with this? If they didn't want to help you when you went through official channels, it would look really bad if some random engineer gave you inside information about how their proprietary software works behind his management chain's back. (And it's telling that you want to talk directly to an engineer, rather than someone who would actually have the authority to grant your request).

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.)


Have you considered the possibility that someone could get fired for helping you with 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.


First, I wasn't trying to shame him at all. I thought it was an ill-advised thing to try to do, and was explaining why I thought that. That's nowhere near the same thing as "shaming".

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.


If people can be tricked into giving away their social security numbers over the phone isn't quite the same as a question asked openly on Hacker News, hence why I said "openly" - open to community scrutiny.

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


I am new to this site, and by far not the programming and code wizards that many of the people here are. However, I think this is a fair question!? I understand both sides to this "debate", but we are talking about a MAJOR player in the music streaming world,for now, and i would think they should be bending over backwards to not only do what the people want, but also the fact and language that everyone understands=MONEY!!! which means make people want your programs/apps more than the next guy, so I think if enough people bring this up to them, it should be handled, or we will all move on, tech moves fast and someone is ready to take their place, any businessman should know this, so I think it would be in their best interest to LISTEN BETTER to feedback, and definitely for the people who are PAYING for PREMIUM service. just my opinion on it, like i said I'm no programmer.


If Spotify fires one of their engineers for helping a third party dev on the weekend, that'd be pretty disgusting... there's plenty ways someone could help OP without revealing IP.

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?


It came to my mind first because I'm at a huge company (read: a high value target for corporate espionage) and it's drilled into our heads from day 1 that answering questions about our business (let alone the architecture of our code!) from outsiders is a very serious breach of policy... the mandated behavior is to reroute them to customer service.

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.


But he's not trying to trick anyone, he's asking an honest question. I understand the concern, but going through life holding ones tongue before every question on the possibility that a bad actor might ask similar questions is like living life in a TSA queue, no thank you.


If your ability to defend from corporate espionage depends on the Bad Guys not asking you questions, then you're not defending yourself from corporate espionage.

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.


What do you possibly gain by being rude? The parent presented some highly reasonably food for thought based on experience within large companies. If the OP has communicated this directly with support, why not consider that maybe something else is going on? Heck, the OP even considered that possibility...


The official channel doesn't want to connect frontend users with developers almost certainly because that's a bad use of their time, in general. How is some front-line support person supposed to be able to filter incoming calls in such a case? Jumping to the conclusion that Spotify doesn't want people _on their own computer_ to know what they're playing seems like a rather big stretch.


No, as a matter of fact, I did not consider that, I'm glad you're pointing that out.


It does on Macs using NSDistributedNotificationCenter. Not sure if there's an equivalent for that on Windows though.


If everything else fails, maybe add support to last.fm? This way the user could just scrobble directly from Spotify to Last.fm and you get the song from there.


@azeirah Just talk to this dude he helped me when I had questions in the past. gh: <https://github.com/thelinmichael email: <thelinmichael@gmail.com>


You should ask support to escalate your request. To someone in marketing.


Last.fm still continues to scrobble because it's a preferences setting not a client plugin(?)

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


That hasn't worked for a while. Was never very good anyway.


I disagree, it was one of the few was to _discover_ music in the Spotify desktop app (with Mobile or Web, you are just SOL). I'm actually working on a webapp for personal use (integrating lastfm) to have some modicum of discovery with spotify. Their internal 'discovery' tools, much like their radio is for lack of a better work terrible.


Use a good old hex editor? Maybe one of the locations is stable enough. I took a quick look at the dump and it doesn't look too hard. Interestingly the js and css is not obfuscated.


Just capture the title from another source instead of the title bar. Spotify is compatible with libre.fm, which is open source. I would use that.


Have you thought about loading up an MITM proxy and seeing what's being routed where and why? That might lead you to a fist-pump or two ;)


Non-premium users, like myself, have a window called 'Spotify Free' - at least on OSX. Might want to look into that on Windows.


Maybe I'm oversimplifying things, but couldn't you just update it to look for the new title string?


The point is that the newest update -doesn't have- the song in its title unfortunately...

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


Just capture the title from another source. Spotify is compatible with libre.fm, which is open source.


Try searching linkedin - its not that hard to find spotify engineering execs on there.


Also if a spotify engineer is reading this email me I have some UI mocks for a few UX fixes in the mac desktop app


I am not a Windows user... but if I were doing this on OS X or Linux, one could look through memory or look at open sockets, though these operations require special permissions.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: