track error

[rodrigoaguilera]

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

[Hexxeh]

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]

I'm getting errors too, for anyone who's keeping score.

[lewiji]

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]

I'm also seeing this, not figured out why yet.

On Sat Apr 06 2013 at 4:13:52 PM, bzuidgeest notifications@github.com wrote:

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.

? Reply to this email directly or view it on GitHubhttps://github.com/Hexxeh/spotify-websocket-api/issues/35#issuecomment-15997761 .

[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]

That the web player breaking for you makes me wonder if there's  something glitching in Spotify's server in addition. Either way that's tough -- my understanding has been that Spotify has approved of 3rd-party APIs  used by Premium members in the past but if they aren't acting that way anymore it's too bad.

[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 :(

[Hexxeh]

Fixed.

[bzuidgeest]

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

[lewiji]

@bzuidgeest https://github.com/TooTallNate/node-spotify-web/pull/14 - basically an encoding bug was worked around in the node spotify api