Move song doesn't work

[CoreDumpling]

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.

[PromyLOPh]

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.

[CoreDumpling]

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]

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).