some playlist entries don't return metadata

[lnhrdt]

Some tracks returned by Mobileclient.get_all_user_playlist_contents() do not contain the 'track' key which contains the track information. I've noticed that these problem tracks have a 'source' value of '1' while the tracks which contain the 'track' key have a 'source' value of '2'. Any ideas?

This is a public playlist with 4 songs which reproduces the problem. Tracks 1 and 2 do not return metadata, tracks 3 and 4 do return metadata. https://play.google.com/music/playlist/AMaBXykCFstQAD9IKhiLDzSMEEgZ3XVCDvJ8iKJcEBh8tGolqtgT_xQ-k0GqJST87C7CvuiP_dI08n1Rs-o0i3yWIWvktPth2A==

[lnhrdt]

This is still a showstopper for me. Any chance someone could look into this with me or give me some pointers for how to look into it myself? I'm still on 3.1.0

[simon-weber]

Sorry, I've been really busy lately =(

There's one easy thing to try, though I doubt it'll work: increment the protocol version number at https://github.com/simon-weber/Unofficial-Google-Music-API/blob/develop/gmusicapi/protocol/mobileclient.py#L23. I don't remember what the most recent one is, but we're definitely a few patch versions behind. It's worth trying 1.2, 1.3... until something breaks.

[lnhrdt]

I just got a chance to try this out. I incremented the version number from 1.1 up to 1.5. None of the versions produced different results. 1.6 breaks.

Thanks for the idea. I'm just surprised this doesn't affect anyone else! Any more ideas?

[simon-weber]

I just looked at this now: I see 3 tracks, all with metadata and of source 2.

Do you have other tracks that currently show the problem? source 1 should mean user-uploaded; presumably these tracks have metadata now because they were matched to AA tracks in the background.

[simon-weber]

Some folks popped into irc to talk about this and we did some digging. Findings:

• this appears to be an intentional design choice
• source 1 == user-uploaded tracks; source 2 == all access
• my hypothesis: given that the mobileclient is a stateful interface, the server can assume that the client already has all information on the user's library tracks. So, it can omit source 1 metadata and let the client fill it in with what they already know.
• when streaming entries from a playlist, trackId will always work

Given that this interface likely won't change, I think I'll expand my interface to do the matching for clients. ie I'll add a new optional param get_all_user_playlist_contents(..., library=None) that when provided as the result of get_all_songs will fill in any missing track metadata. @lennyk would that work for you?

If this kind of situation becomes more common, we may need to revisit #151 or consider moving to an ORM-like interface.

[openSourcerer9000]

Any update on this?? Desperately trying to migrate to spotify but my playlists are coming out 50% NaN's. I have no uploaded tracks, it seems to be a bug that I'm getting sources of '1'.

[simon-weber]

I actually used the debug interface from Autoplaylists to do this instead of using gmusicapi. It uses the web interface, so the data should actually match what you see online.

I've got a link to the Autoplaylists docs in https://gist.github.com/simon-weber/333753fc295983cf40fba5eb6ec5e643, along with some example code for handling the resulting csv (though most of it is Mediamonkey-specific).

edit: whoops, I wasn't paying attention. I thought you meant you weren't able to list your library's songs, not that you were trying to get metadata for songs in a particular playlist.