Could getting track artwork be less intensive on the server?

[philipbulley]

Looks like TrackController.getArtwork() will make a request to the server for adata:image/jpeg;base64 blob each time it needs artwork.

• :rage: Intense on a Raspberry Pi already playing back music. We need artwork for the currently playing track + thumbnail for every track in playlist.
• :rage: It may/may not implement caching in the node-spotify lib.
• :rage: It might be convenient using the node-spotify API, but might not suit other API implementations that would require us to make and cache HTTP requests ourselves.

I haven't checked the APIs to see if it would be possible, but can I suggest we either:

1. Store URL(s) to an artwork file on the Track. This is fetched when we first create the Track. If possible 2 images, one large and one smaller for thumbnails. Clients can make all requests.
   • :rage: Potential for dead links in DB if provider uses expiring thumbnail images, if that's the case we'd have to go for point 2...
2. Get the client to access the provider's API to get image URL based on the Track's provider and foreignId.
   • :rage: Requires provider's API to be implemented both client-side as well as server side. Uhh.

[ianmcgregor]

Yeah we should look at the node-spotify source to see what they are doing re images. This does seem like a strange, inefficient way serve them.

[ianmcgregor]

Had a look. The images are c++ byte arrays in libspotify and then are converted to base64 by node-spotify.

We might be better off retrieving artwork urls from the web api. They have nice large images too!

https://i.scdn.co/image/4ca55ab16f598335b52c9f2103708042d85e2ad2

https://developer.spotify.com/web-api/console/get-track/

https://developer.spotify.com/web-api/endpoint-reference/

[ianmcgregor]

Have swapped out the heavy libspotify method for a web api call. See 52ee760

Just sending the URL at the moment, there's an array of different-sized images with width/height info if that's useful.

"images" : [ {
      "height" : 639,
      "url" : "https://i.scdn.co/image/6aa7e0715b0927c494679037d45cb52afaeef742",
      "width" : 640
    }, {
      "height" : 300,
      "url" : "https://i.scdn.co/image/0dd82fb4d865d4f6e0bd04367b9bb83df4ff5a47",
      "width" : 300
    }, {
      "height" : 64,
      "url" : "https://i.scdn.co/image/7d6ce13d0c34251d9bc6c58e95885ebcc40be3d2",
      "width" : 64
    } ]

At the moment there's no caching. Would make sense to add this URL to the track object so we don't request for every client.

Not sure if those URLs are permanent either, so could either use an in-memory cache or request it again if and when we get a 404. What do you think?

[philipbulley]

Adding to the Track object is a good idea and width/height will be very useful.

Shall we proceed as if they are permanent URLs, then the end user's client can just request the URL. No need for any image requests on the server. If we later see that we need some kind of test/expiry, we can formulate an approach then?

[ianmcgregor]

Yeah let's try it. Makes me wonder whether it's worth looking further into the web api as it's probably likely to stick around longer than libspotify and could make migrating to whatever replaces libspotify less painful.