I think Google photos announced an API… That would be a useful endpoint… Wink wink
2 Likes
Oh my god, please! I have been waiting for an official API for a while. This is the only reason I have Backup and Sync installed. If rclone could replace it, that would be a godsend.
OH MY. This is the BEST NEWS. I have been using the stupid Picasa Web Albums API daily for like 5 years.
(If you’re curious why, it’s for this: https://github.com/mholt/photobak - a little program I wrote that downloads your Google Photos.)
There is an issue about this: https://github.com/ncw/rclone/issues/369
If anyone would like to add useful links to that I’d be grateful!
Nice!
I make my google photos appear in my drive which you only have to do once then I use rclone to back them up.
1 Like
But I think this way photos will use the Gdrive space, right? I think it would have to be through the API to enjoy unlimited space.
1 Like
Yep. And I’ve also experienced some weirdness when I enable Photos in my Drive; so I just decided to turn it off.
I only ever read from the google photos and it has worked fine for that. I haven’t tried uploading photos though…
Very good news, not a minute too soon - Google Photo Uploader dies on the 14th!
I’ve used gphotosuploader with success, but that’s pretty rough.
I’ve tried that, but Google won’t put them all in that folder on my main account, on smaller accounts it works fine and puts them all in Year folders but my main one only has 160 photos out of 1000’s and they are all in the root Photos folder.
I’ve also looked through the new Google Photos API docs and it doesn’t look promising, I can’t find an option to retrieve the original photo. I think this new API isn’t really geared around backup and restore.
My Samsung phone embeds the live images into the JPEG container, this is stripped out when retrieving the photo by the API, the photo is 5.7MB raw and only 1.9MB when retrieved by the API, plus the API strips the Geo Location info and all the other EXIF info. Not impressed with it yet anyway 
I think this bit from upload media docs won’t please people either who were hoping for unlimited uploads
Note: All media items uploaded to Google Photos through the API are stored in full resolution at original quality. If your uploads exceed 25MB per user, your application should remind the user that these uploads will count towards storage in their Google Account.
Aw man :I That’s sad. Maaaaybe it’ll improve…
I mentioned previously in this thread that the Google Photos folder doesn’t work for one of my accounts, just in case anyone else has a similar issue I used Google Takeout to create an archive in zip format of my photos in Drive. https://takeout.google.com It takes a while but appears to be working, if it doesn’t I will comment back here.
1 Like
REviving this. Is this worth creating an issue for?
https://github.com/nmrshll/google-photos-api-client-go
Seems with the new API, we can upload to google photos which would be really nice feature to incorporate within rclone.
sure. and done. Its a pretty specific feature but would be interesting none-the-less.
1 Like
Just some more ‘meat’ for this thread. I was playing with that API go tool that I listed above and it works okay (after slowing it down since it gets lots of rate limiting by using rclone’s own '‘tpslimit’ on a mount 
)
Thing we should note here though is that Google Photos “EXPECTS” duplicates in the mount so whatever is written would really need to account for that. When you upload with the API it places the photos in the Google Photos service and then they “appear” in the Google Photos folder in google drive under a ‘year’ heading. You can imagine that when uploading years of photos, you’ll have MANY that have the same name under a ‘year’.
2018:
DSC_0001.jpg
DSC_0001.jpg
They store correctly and are using by the Google photos API rather well with those duplicates. WHen you delete one of those from hte front end, it correctly deletes ‘one’ of those from the drive folder in the backend. That being said, if this was implemented within rclone, it would really need to be duplicate aware and drive off of the ‘hash’ only for syncing rather than the path (since its stripped into a flat by year) The year folders it places the resulting files in come from the EXIF tags rather than anything else which also can be problematic for doing actual syncs.
The more I looked into this, the more I think this may not be the best integration into rclone since it doesn’t follow any of the rclone design. That being said, portions of the rclone code could be used to make a ‘copy’ tool that worked.
Just some food for thought. On a positive note, I was able to fully recreate the google photos library that I can browse with the google app/web with about 150,000 photos.