Mobileclient.rate_songs is buggy for searched songs that are also in the library

[oprypin]

I was using Mobileclient.search, aggregated results from a multiple searches, and put them into .rate_songs(results, '5'). What I noticed is that songs that happened to be in my library were all unaffected by this call, while all others were successfully thumbed up.

Then I used .get_all_songs() and matched them by storeId and replaced the previous results with these library results whenever possible (these have the id in them).
I got the following error:
gmusicapi.exceptions.CallFailure: BatchMutateTracks: the server's response could not be understood. The call may still have succeeded, but it's unlikely.
(response was: '')
But the songs were successfully thumbed up anyway.

Because this was a one-time project for me and I found a workaround anyway, this is not an important issue for me, but I thought I'd let you know.

[simon-weber]

Huh, weird. I've only ever seen the inverse (library tracks working fine, but non-library tracks causing issues).

[thebigmunch]

There's a fair chance this is because the endpoint used to rates songs in gmusicapi isn't actually how the Google mobile clients do it. They only allow you to rate songs while playing them. And it uses the activity/recordrealtime endpoint or maybe just the activity/record endpoint (I seem to have lost my capture for this and can't check it on Android 7).