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

Fix missing / unavailable tracks in search results #131

Merged
merged 1 commit into from
Jun 11, 2017

Conversation

kingosticks
Copy link
Member

@kingosticks kingosticks commented Feb 3, 2017

This fixes #97 by setting the market parameter when doing searches using the Web API.

We don't currently set the parameter and it defaults to 'US' (spotify/web-api#194). Depending on the logged in user's country, this may result in missing or unavailable tracks being returned. For example "The black box revelation" as reported in #106.

I appreciate that considering #130, this might not see the light of day, but at least this should remind us to set it as part of those future changes.

Copy link
Member

@trygveaa trygveaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Can you squash the two commits? (commit --amend is nice when fixing flake errors)


try:
params['market'] = session.user_country
except ValueError as exc:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this ever happen?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know, but remember, this is libspotify....

Copy link
Member Author

@kingosticks kingosticks Feb 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess if we were really worried about libspotify returning rubbish back to us we should handle it in pyspotify. I can remove this (and it's test).

Copy link
Member

@trygveaa trygveaa Feb 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, in libspotify it is an int and pyspotify doesn't raise any errors no matter what the value is, so I don't see how anything could happen. If the int is 0, you will get null-bytes, but that shouldn't trigger a ValueError.

Edit: Posted this before I saw your last answer. In response to that: Well, if pyspotify raised a ValueError on invalid values from libspotify this would make sense, but as far as I can see, it doesn't do that.

Copy link
Member Author

@kingosticks kingosticks Feb 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that returned int is greater than 65535, then utils.to_country will raise ValueError when it tries to convert a number greater than 255 to chr. That routine could do with another & 0xff in there.

@kingosticks kingosticks force-pushed the fix/search-tracks-available branch 3 times, most recently from 84f63ea to e7247a6 Compare February 3, 2017 18:00
@kingosticks
Copy link
Member Author

Squashed and I've also removed the exception handling from this PR. It'd only be needed if libspotify started misbehaving (which we have zero reports of), in which case it should be handled in pyspotify rather than here.

@jodal
Copy link
Member

jodal commented Jun 7, 2017

Is this necessary now when all requests are authenticated? Couldn't Spotify know from your credentials which market you're in?

@kingosticks
Copy link
Member Author

You'd hope so, but not quite. From https://developer.spotify.com/web-api/search-item/:

If from_token is given and a valid access token is supplied in the request header, only items with content playable in the country associated with the user's account will be returned. (The country associated with the user's account can be viewed by the user in their account settings at https://www.spotify.com/se/account/overview/). Note that the user must have granted access to the user-read-private scope when the access token was issued.

If you don't specify anything, you used to default to US but I'm not sure if that's still true.

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

If market=from_token is supplied in the query string, the current user must have authorized the user-read-private scope.

So yeah, we do need the scope even if we never directly look it up.

@jodal
Copy link
Member

jodal commented Jun 7, 2017

And @kingosticks needs to update this PR to apply to develop again :-)

@kingosticks
Copy link
Member Author

Well that didn't work

@kingosticks
Copy link
Member Author

That's better!

@jodal jodal added this to the v3.2 milestone Jun 8, 2017
@jodal jodal merged commit 4e9b82c into mopidy:develop Jun 11, 2017
@kingosticks kingosticks deleted the fix/search-tracks-available branch February 26, 2019 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants