gmusicapi
gmusicapi copied to clipboard
simon-weber
Feature request: Upload external album art
I'd like the ability to upload non-embedded album art (I don't embed art because it's a waste of disk space).
There doesn't seem to be a way to do this with the API as far as I can tell, so I was wondering if it would be possible to look in the folder that the song to upload is in for cover.jpg/folder.jpg/whatever and upload that (by adding the image on-the-fly with ffmpeg or using some endpoint).
There's http://unofficial-google-music-api.readthedocs.org/en/develop/reference/webclient.html#gmusicapi.clients.Webclient.upload_album_art, which should do what you're looking for.
For what it's worth, I don't think embedded art will be uploaded right now (https://github.com/simon-weber/Unofficial-Google-Music-API/pull/215 has a failing test for that).
It's just a pain because it means authenticating twice (once with oauth and then again with user/pass)
Ah, yeah; I understand. The music manager protocol is capable of this but it's not implemented yet (that's what the test is for).
I'll take a look with fiddler and try to figure out both password auth for music manager and album art quickly.
The music manager can be annoying, since everything is protobufs and it uses cert pinning. Feel free to shoot me an email; I can set you up to work with it.
Looks like we need to upload some sort of hash of the album art... It looks like a sha256 hash, but I tried hashing an image and it doesn't match up. Any ideas? I've tried to strip EXIF tags, but that didn't work.
Can you upload an example image and hash? I'll fiddle around with it.
Stripping EXIF tags was a good idea. Track hashing happens after metadata is (mostly) stripped.
Maybe there's a pre-hash transcode step? We could compare the original file to what ends up on Google's servers.
If we can't get it to mach it might not be a blocker: I don't send matching hashes for track upload, either.
http://simg.co.nr/s/500x500.jpg GMusic sum: 6cf4218124657ff0ac54ac40efe194c345e96e21b981b02e45a9aaae80b3f521 sha256sum: 6a4cb8e33bf6b926fd0d495e51a692e87c6423d3987fea5a3a7a3a2d689a38e2
Edit: uploaded the non-stripped version accidentally, so updated to reflect stripped version.
And the sum for the uploaded file after downloading from Google's servers here: 865d4ac503ff7160d762b416b9079108676d3dcf58503569ae7e5d99c27446bc
!?!??!?!!?!?!!
Update: I'm stupid - running a simple mogrify -compress JPEG 500x500.jpg gets the same result as the google server version.
I'm fine with sending a non-compliant hash.
How far along are you with this? I may have time to look at it if you're busy.
Not far at all. I think it's pretty much a hit or miss at this point, and it looks like the webclient actually uploads using a non-compliant hash as well, so....
Hey guys,
any news on this issue? I've been trying to figure out why uploaded songs via the python api don't show any album art - until I found this issue.
If I add the album art later by the method using the webclient - the cover will not be displayed on the mobile client. (I don`t know why that is, it works though perfectly on the webclient).
For any tipp for working this out, please let me know
I haven't worked on this issue recently. The issue with art not showing on the mobileclient is interesting -- have you tried doing a refresh to see if maybe the updated metadata just hadn't been pulled down yet?
Hey,
I investigated the issue with the artwork yesterday a bit further. When I manually add the cover art via the webpage of google - it will appear in the mobile client. When adding it via python api, it would not appear.
When comparing the differences, I noticed that the python api saves an url with "=s130-c-e100" as albumart. But the webpage would save it without it.
I.e. Python Api saves: http://lh5.ggpht.com/tAY7M7A_byOYVltHrHGzfWWvsJAQpbCrQoFTbPCDQVfxFcg6jpH18kSqQTaV=s130-c-e100 But google would save: http://lh5.ggpht.com/tAY7M7A_byOYVltHrHGzfWWvsJAQpbCrQoFTbPCDQVfxFcg6jpH18kSqQTaV
The first way of saving the cover art does not seem to work on mobile devices - when saved in the second format without the added "=s130-c-e100" it works without any trouble (online as well as in the mobile client).
I now manually strip the part of the url after the upload and change it - would probably be better to already do that in the api here?
great work, @patrickjahns. yeah, it sounds like we're just making outdated requests or something.
Here's some code that might be useful for uploading external and embedded art: https://github.com/simon-weber/gmusicapi/issues/352#issuecomment-115009753.
Any idea how to fix this? This is the only issue I have with the API -- everything else working perfectly! If there's anything I can do to help testing, please let me know.
I gave up on trying to get Musicmanager art to show. Instead, I start using Webclient.upload_album_art, and now it's semi-working.
However, while the art is showing just fine via the web UI, it is not showing via the iPhone app. Is this a known issue? Are there any workarounds to get it showing in all clients?
I think https://github.com/simon-weber/gmusicapi/issues/242#issuecomment-59946065 is referring to the same problem.
Ah, I missed that one. Sounds like he has a solution though. I'll try it out. Any idea what API I would use to update the art URL? I'm assuming it would be Mobileclient.change_song_metadata, however, the documentation states that "only the rating key can be changed".
Yes, I tried changing the URL as mentioned in this comment, but it's not actually doing anything, even though I do get a valid 'id' back as the response.
song['albumArtRef'][0]['url'] = re.sub(r'=s130-c-e100$', '', song['albumArtRef'][0]['url']) Mobileclient.change_song_metadata(song)
It appears the API is broken. Is there any other way to change metadata beyond this method?
Oh, right, Google disabled that api. I don't think we have any alternatives at the moment (see https://github.com/simon-weber/gmusicapi/issues/224).
I fixed Webclient.upload_album_art -- art is now showing correctly in all clients
In /gmusicapi/clients/webclient.py
Add In Head: import re
Replace: url = res['imageUrl']
With: url = re.sub(r'=s130-c-e100$', '', res['imageUrl'])
So, I've looked into uploading album art with the Music Manager. It was actually quite trivial as far as the protocol is concerned. I'll probably get around to making it properly in the next week or two when I have time, as I just hard-coded everything in the ProvideSample call class to test it.
My initial thoughts on the interface is: upload(..., album_art=True|False|"/path/to/image"). This would default to True, as is the case with Google's Music Manager, unless a strong case is made otherwise.
To make sure I'm following: True meaning "embedded art"? Seems reasonable to me.
To make sure I'm following: True meaning "embedded art"? Seems reasonable to me.
Correct.
Alright everyone, it's not ready for a PR yet because it's based on my future-fix branch (which hasn't been merged yet), and I haven't added anything to the tests for it. But, the meat of it should be ready to go.
Give it a try with pip install git+https://github.com/thebigmunch/gmusicapi@upload_album_art and let me know if you run into any problems.
The parameter is named include_album_art. It defaults to True, which will upload embedded album art for all supported files. Set to False, it won't upload any album art. When set to a valid filepath, it will to upload that. If its not a valid filepath, the song is uploaded without album art. If that file is not a valid, supported image file (JPEG, GIF, PNG), Google simply throws it away on their end.
So, a quick update on this. When I went to add a test, I discovered (as I probably should have guessed) that Google does not request a sample for some tracks (assuming based on duration). This is important because the way I implemented it (as per my observations of actual Music Manager process) was to send the album art data in the appropriate field when posting the sample request. And, as I've done a little testing, if it's based on duration, it's a much longer duration threshold than I anticipated.
So, I started by updating the protobuf definitions to see if anything else obvious had been added to the UploadMetadata call or the Track definition. There was an added field track_extras which allowed additional metadata to be included. Songs with album art had an ALBUM_ART_HASH added here, but being a hash it doesn't appear useful. The Track definition already included a field for an album art ref, but this only seems to be used for URLs.
And that's how far I got before I had to stop for a bit. Next step is to remember (or bug Simon to remind me) how to patch the MusicManager binary so I can capture calls from the current version. I'm not sure when I'll get back to it, but I hope to start working on it again by the end of the week.
Would love to have an update on this and/or some guidance on how I might be able to get set up to try and figure this out :)
Hey, so is there any update on this? Was making an online Play Music Manager, which is working pretty well except for the album art. Any way to upload either embedded or non-embedded art? Can't use webclient since it's an online application and plaintext password would mean a huge security vulnerability.
You could check the branch 'upload_album_art' in @thebigmunch's fork, or my fork (which just merges this branch into develop) for an implementation where uploading album art through code works fine. I have been using it for the past year on a project and for the most part, it works. I have had some issues but I do not know if those issues relate to this implementation, or the source image file itself (but it doesn't really matter to me that much so haven't looked into it).
Alright, thanks! I'll take a look into it. Why was it not merged into the master branch, though?
On Thu, May 17, 2018, 12:34 Opender Singh [email protected] wrote:
@FadedCoder https://github.com/FadedCoder you could check the branch 'upload_album_art' https://github.com/thebigmunch/gmusicapi/tree/upload_album_art in @thebigmunch https://github.com/thebigmunch's fork, or my fork https://github.com/develohpanda/gmusicapi (which just merges this branch into develop) for an implementation where uploading album art through code works fine. I have been using it for the past year on a project https://github.com/develohpanda/ytdl and for the most part, it works. I have had some issues but I do not know if those issues relate to this implementation, or the source image file itself (but it doesn't really matter to me that much so haven't looked into it).
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/simon-weber/gmusicapi/issues/242#issuecomment-389766230, or mute the thread https://github.com/notifications/unsubscribe-auth/AQjZIY2XM4r5Fhe01f6-ghyGUcEEZXXLks5tzSEEgaJpZM4B2pP_ .
--
Best, Soham Sen.
AFAIK It was an experiment by one of the devs and was not fully supported against the main project. Reason why I merged to dev on my fork was because it was branched from dev in the first place. :)
Ah okay, understood. Thanks!
On Thu, May 17, 2018, 14:32 Opender Singh [email protected] wrote:
AFAIK It was an experiment by one of the devs and was not fully supported against the main project. Reason why I merged to dev on my fork was because it was branched from dev in the first place. :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/simon-weber/gmusicapi/issues/242#issuecomment-389797043, or mute the thread https://github.com/notifications/unsubscribe-auth/AQjZIfmmlxB1dViJVMlWKh_O-1QJ5PEvks5tzTyTgaJpZM4B2pP_ .
--
Best, Soham Sen.
Frankly, I ended up writing my own Google Music API libraries (sans-io and concrete) as well as an audio metadata library to get client ID generation correct (and provide much better API than existing projects) but haven't release them yet (definitely should have by now, but life). That's why I've done nothing more with this. Though, the fresh look at things did help me find the solution to this. For anyone who wants to try finishing this in gmusicapi, there is an inlined 'AlbumArt' key that can be sent in the POST call to scottyagent that takes the b64encoded byte data of the picture. Adding this to what I already added in the sample call should get things working as they're supposed to. Whether the API for exposing this to the user is still the best vOv.