3 ms·

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 sen

by j42 12y ago

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

hackmiester 12y ago
> 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.)
- Pxl_Buzzard 12y ago
  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?
- j42 12y ago
  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.
mts_ 12y ago
> 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 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 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())

by j42 12y ago

hackmiester 12y ago

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

Pxl_Buzzard 12y ago
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?
j42 12y ago
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.

mts_ 12y ago

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