Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spotify provider #16

Closed
phw opened this issue Jun 7, 2024 · 6 comments · Fixed by #22
Closed

Spotify provider #16

phw opened this issue Jun 7, 2024 · 6 comments · Fixed by #22
Assignees
Labels
feature New feature or request provider Metadata provider

Comments

@phw
Copy link
Collaborator

phw commented Jun 7, 2024

Implement a Spotify provider based on the Spotify Web API.

Implementation notes:

  • General API access should be very similar to the Tidal provider, including the client credentials auth flow.
  • Individual regions don't seem to be queried separately. Instead the API when queried without a "market" set returns a list of all markets the release is available on.
  • Primary type (Support release group types #15) could be supported, at least for single and compilation types.
  • Fetching the full track list for an album can involve multiple calls, the initial result from the album request only contains the first page of tracks.
  • ISRCs are available, but seem to require a separate call, as the track info being returned as part of the album exclude this data.
  • Pad GTIN with zeros if no results are found (example). a-tisket already does this. See also Roadmap #6
  • Spotify has a concept of Track Relinking, where tracks not being available in a specific market get swapped out with a similar track that is available. Not sure about the implications, we'll need some examples for this. Might be that if the data gets queried without region that the relinking is not indicated. If this can be detected it would at least be good to show a warning.
  • Copyright information gets returned with separate entries for © and ℗. Because this is clearly separated the entries not always contain the corresponding symbol. If we just import the text the entries cannot be distinguished. The provider should add the symbols based on type if not present in the given text.
  • Similar to Deezer label info is a single text that sometimes contains multiple labels separated by /.

Related to #5

@phw
Copy link
Collaborator Author

phw commented Jun 7, 2024

@kellnerd What is the state here? Has someone already done some work for Spotify support? Would you mind if I'd give this a go?

@kellnerd kellnerd added feature New feature or request provider Metadata provider labels Jun 7, 2024
@kellnerd
Copy link
Owner

kellnerd commented Jun 7, 2024

@RustyNova016 had expressed interest on the forums:

I’m a Spotify main so I don’t really have an use rn.
I’ll see to learn about the project and help implement it. If I got time.

But no clear commitment so far, so I will assign the issue to you @phw.
That would be the process I hope to establish per my initial notes on #5 at least.

@kellnerd kellnerd mentioned this issue Jun 7, 2024
17 tasks
@phw
Copy link
Collaborator Author

phw commented Jun 8, 2024

Some notes about the Track Relinking for future reference: For now this does not seem to affect the provider. The track relinking is only happening if requesting a track from the API with a specific market set. Otherwise no relinking is happening and the available markets are simply indicated with the available_markets attribute.

Here are shortened replies for the example track 6kLCHFM39wkFjOuyPGLGeQ. When requesting with market set to US:

/v1/tracks/6kLCHFM39wkFjOuyPGLGeQ?market=US

The result is a mix of the originally requested track and the actually returned track. That relinking happened is indicated by the linked_from field. Also when requesting with a market is_playable shows if the track is actually playable there (it is in this case, but only because relinking happened). There is never a available_markets attribute.

{
  "id": "4gNlDPuBlf3rxkxRaDTAvf",
  "name": "Heaven and Hell",
  "duration_ms": 243053,
  "track_number": 7,
  "linked_from": {
    "external_urls": {
      "spotify": "https://open.spotify.com/track/6kLCHFM39wkFjOuyPGLGeQ"
    },
    "href": "https://api.spotify.com/v1/tracks/6kLCHFM39wkFjOuyPGLGeQ",
    "id": "6kLCHFM39wkFjOuyPGLGeQ",
    "type": "track",
    "uri": "spotify:track:6kLCHFM39wkFjOuyPGLGeQ"
  },
  "is_playable": true,
  "external_ids": {
    "isrc": "USLB11110086"
  },
  "external_urls": {
    "spotify": "https://open.spotify.com/track/6kLCHFM39wkFjOuyPGLGeQ"
  },
  "uri": "spotify:track:4gNlDPuBlf3rxkxRaDTAvf",
  "href": "https://api.spotify.com/v1/tracks/6kLCHFM39wkFjOuyPGLGeQ",
  "preview_url": "https://p.scdn.co/mp3-preview/9ff410684525dec4e22c322ba38a9ca4f9a4cf1c?cid=cfe923b2d660439caf2b557b21f31221",
  "type": "track"
}

If doing the same request but without the market=US parameter the result changes to:

{
  "id": "6kLCHFM39wkFjOuyPGLGeQ",
  "name": "Heaven and Hell",
  "duration_ms": 243053,
  "track_number": 7,
  "available_markets": [],
  "external_ids": {
    "isrc": "USLB11110086"
  },
  "external_urls": {
    "spotify": "https://open.spotify.com/track/6kLCHFM39wkFjOuyPGLGeQ"
  },
  "uri": "spotify:track:6kLCHFM39wkFjOuyPGLGeQ",
  "href": "https://api.spotify.com/v1/tracks/6kLCHFM39wkFjOuyPGLGeQ",
  "preview_url": "https://p.scdn.co/mp3-preview/9ff410684525dec4e22c322ba38a9ca4f9a4cf1c?cid=cfe923b2d660439caf2b557b21f31221",
  "type": "track"
}

The result now fully represents the requested track. Both linked_from and is_playable are never present. Instead the result now contains the list of available markets in available_markets. Side note: The list is indeed empty here, but only for this example, which seems to be available in no market at all. For all other cases I tested the list was filled.

@phw phw mentioned this issue Jun 8, 2024
@RustyNova016
Copy link
Contributor

@RustyNova016 had expressed interest on the forums:

And I still do! But this week and probably the next is quite a wild ride so I can't really do anything for now.

@phw
Copy link
Collaborator Author

phw commented Jun 10, 2024

And I still do! But this week and probably the next is quite a wild ride so I can't really do anything for now.

@RustyNova016 Sorry if I got in the way. I was just very keen on having this tool to support Spotify, so I started right away. But please definitely take a look at Harmony if you want to improve something. I found it a pleasure to work with the code. It is really extensible, and I think already better in its current state than a-tisket. There is likely a lot that could and should be added, but with this codebase it will actually be doable :)

@RustyNova016
Copy link
Contributor

Nah it's fine. With features like this the faster they are done, the better. Even more that I got other projects to work on.

I did check the codebase a bit and it looks pretty clean, but without enough comments. Do want to get a docker environment started first before doing work still.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request provider Metadata provider
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants