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

Already on GitHub? Sign in to your account

Move song doesn't work #280

Closed
CoreDumpling opened this Issue Jun 24, 2012 · 3 comments

Comments

Projects
None yet
2 participants

Note: I'm inclined to believe that the problem is on Pandora's end, but I'm opening the issue here to see if there's any other ideas.

Using 'm' to move a track to another station does not achieve the desired result. The expected outcome is that the track is given thumbs-down on the current station, and thumbs-up on the destination station.

What actually happens is that 'm' simply gives a thumbs-up to the track on the current station.

I've looked into the behavior and as currently implemented, pianobar uses the JSON v5 API method station.addFeedback. What I've observed is that the stationToken is ignored, and that the trackToken seems to have sufficient information for the feedback to be registered on the server. As a consequence, the thumbs-up will cancel out the thumbs-down given on the same station.

If the implementation is changed such that the order of the thumbs-up and thumbs-down is reversed, the thumbs-down will cancel out the thumbs-up on the current station, but the destination station will be unaffected.

It's been rather frustrating to figure out how this really ought to work, since I don't have a working example of the correct approach anywhere. The Pandora web-based client still uses the XMLRPC v34 API, which appears to respect the station token, but it provides no insight with regard to the JSON interface. The Pandora One desktop client doesn't even implement the "move song" capability, and I don't know if any of the mobile clients have it either.

On a couple of occasions I have been able to modify the track token by copying and pasting chunks of the hex string from one track to another to get the thumbs-up to take effect on a different station, but it's very hit-or-miss and I still haven't figured out a logical mapping from stations to some substring of the track token. Most of the time I get "invalid station" or "internal error" instead.

A possible workaround would be to fallback to using XMLRPC for this particular action, but I'd imagine that's a pretty ugly hack that might break again in short order, so it's probably too much effort for too little gain.

Owner

PromyLOPh commented Jun 25, 2012

Somehow I came to the conclusion the stationToken worked, see
c4330c3. However I can’t reproduce
it, so you’re probably right and the station is encoded in the
trackToken. The trackToken seems to be random to me, though.

The trackToken is still rather opaque to me, but there are definitely patterns to be noticed.

The length is either 96 or 112 characters.
The substring from trackToken[16] to trackToken[47] is often the same for tracks from the same station, but not always. Sometimes there are two or three values that appear repeatedly in this range.
The substring from trackToken[48] to trackToken[79] also seems to have a small number of values that show up repeatedly within the same station.

PromyLOPh added a commit that referenced this issue Jun 26, 2012

piano: Remove move song
Doesn’t work with JSON API. See #280.
Owner

PromyLOPh commented Jun 26, 2012

I removed the move song feature. Perhaps “create station from song” is
meant to replace it on mobile devices?

Moving back to XMLRPC is not an option and I doubt we can reliably
manipulate/build trackToken anytime soon although there exists a pattern
(16-32-16-32-16, 32 bytes could be MD5).

@PromyLOPh PromyLOPh closed this Aug 12, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment