Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

track error #35

Closed
rodrigoaguilera opened this Issue · 18 comments

10 participants

@rodrigoaguilera

Today 26-04-2013 I'm getting track errors for everithing. I have premium. Am I alone?

@Hexxeh
Owner

No, I'm seeing this too. CloudFront is giving 403s. I've not had time to look into it yet.

@bradleyjones

Same behaviour here

@TooTallNate

That's strange. My lib has been working all day. I'm not sure what the difference would be.

@elliottwilliams
@lewispollard

Me too. Might be related to the recent DDOS attacks on CDNs?

@offermann

Same problem here. First, it only happened for same tracks. Since a couple of days, I get the track error on all tracks when calling track_uri from spotify.py. Did Spotify change the protocol?

@bzuidgeest

Could anyone tell me if this problem still exists? I'm not a python man, so I tried rewriting the code to c#. It seems to be working mostly, but I cannot get any tracks from spotify. using sp/track_uri.only gives me an url some of the time. most times I just get a {"error":[1,0,""],"id":5} back. When I do get an cloudfront url back I get 403's. using fidler I cannot see any differences in my request and that of the spotify player. I replicated every header. Also when capturing websocket sessions of the spotify player in chrome I see sp/track_uri commands with just the gid? hex value in stead of the larger all number id. But replicating that results in an error to. Just can't figure if it is my code or spotify changing things.

p.s. if anyone is interested I would publish the code (alpha as it is) but I want it working first.

@Hexxeh
Owner
@mediate

Just a warning - I looked at this and was pleased to find that the track errors went away if the correct dowork message result was returned consistently. Seemed like good news. (I used python-spidermonkey to evaluate the javascript in the dowork message payload). Unfortunately the cloudfront urls returned by sp/track_uri are still bogus. Worse, my account is now apparently permanently crippled - the official webclient is also now fobbed-off with these same fictional and useless cloudfront urls for all tracks accessed from my account. (Other logins, even from the same IP address, still work fine with the official client). My account has been crippled like this since Saturday, so not a temporary block it seems. Apparently Spotify really don't want anyone using an unofficial API any more.

@elliottwilliams
@bzuidgeest

I got a breaking web player too sometimes, saying that tracks could not be found. But restarting the browser (FF) (completely all tabs sessions) always fixed that for me. I think that elliott's suggestion is the most likely. The script does something wrong and the spotify server gets confused. Is the player officially out of beta? Also the c# webclient does not use/share the desktop cookie jar and other browser (ie ff) based resources. This might also explain why in my case the official webplayer fixes itself more easily.

As I consider my primary targets for development in c# to not be web based I ignore the javascript doWork messages. Maybe I should look at them some more, for clues.

To bad spotify does not document this api.

@mediate

Its not a browser issue - the account is blocked from all browsers, all OSes, all networks (tried home, work) and different IPs by all LON (London) access points. At present just one of the STO (Stockholm?) access points still works for me, perhaps because its account replication is slow or broken. I had the 'temporary confusion' too, but I think if you persist it becomes a hard block. Call me paranoid, but I don't think it is a bug, I think it is a deliberate anti-hacking measure. After all, the bogus URLs only superficially resemble real ones - its not just that the query string parameters are incorrect.

If you're feeling lucky, make sure that the dowork work is done correctly. (I checked that it gave the same result as the official web client). The javascript payload looks like rubbish but is syntactically correct and will evaluate. NaN results occur sometimes, but these are also returned by the OWC.

I used

from spidermonkey import Runtime
...
if cmd == "do_work":
    Logging.debug("Got do_work message, payload: "+payload)
    rt = Runtime()
    cx = rt.new_context()
    workresult = cx.eval_script(payload.replace("this.reply",""));
    Logging.debug("Work payload eval: "+str(workresult))
    self.send_command("sp/work_done", [str(workresult)], self.work_callback)
@TooTallNate

Call me paranoid, but I don't think it is a bug, I think it is a deliberate anti-hacking measure.

I'm gonna call you paranoid, since my node-spotify-web module is still working at this time. There's probably just some very minor differences in the bytes we're sending to Spotify, but it's hard to diagnose (for me at least) since it's all over a secure socket.

@bzuidgeest

If you want to see the socket traffic install google chrome. I'm not a fan of that browser. But it has an inbuild ability to monitor traffic over websocket connections including wss spotify is using.

@richard-ive

Any progress on this? I've hunted around, but no luck I'm afraid :(

@TooTallNate TooTallNate referenced this issue in TooTallNate/node-spotify-web
Merged

proto: change contentType to bytes format #14

@Hexxeh
Owner

Fixed.

@Hexxeh Hexxeh closed this
@bzuidgeest

Can I inquire as to what/how it was fixed?

@lewispollard

@bzuidgeest TooTallNate/node-spotify-web#14 - basically an encoding bug was worked around in the node spotify api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.