Nick Steel

You can see the login5 code uses the client id from the session. There are also session methods to change the client id. Does that work? I can't remember. Go...

> Oh I missunderstood the question. I think I never tested it with other client_id's. But working with login5 is quite pin pointing, one wrong variable and it would report...

That's annoying if true. But you can just use their client ID for everything you do.... Given how hell-bent they are on screwing over legit devs I see no reason...

I don't understand what you are saying there, but yes, anyone is free to implement the regular Spotify OAuth flow themselves. We are not going to provide a wrapper around...

The only thing left to do here is to deprecate keymaster or not. Ideally someone needs to have a quick play and decide if it really is entirely broken now...

I only meant we could switch out `hm://keymaster/token` with login5 in `TokenProvider`. Am I forgetting why that would impact getting track encryption keys? Although, you raise a good point that...

There are some rate limiting error codes in the esdk ( kSpErrorAPIRateLimited, kSpErrorPlaybackRateLimited, kSpErrorSkipLimitReached), and they've been there for a while, but I can't tell if it was before switching...

> a better fix if we could get the Retry-After header What header? From where? There are no headers for Mercury requests like this. I don't recall any rate limited...

Can someone give me an example of how much skipping needs to be done? I was trying to reproduce this earlier by manually skipping and I failed.

But is this all really worth it to avoid some copying? The event frequency is always going to be relatively low, isn't it?