search

andrewjjenkins / picsync

Sync Google Photos albums to a Nixplay Seed web picture frame
Apache License 2.0
18 stars 2 forks source link

Big picture questions #11

Open anitschke opened 1 year ago

anitschke commented 1 year ago

I currently use the Nixplay supported Google photos dynamic playlist, however Nixplay sent out an email announcing that this functionality will now require a subscription.

We are writing to inform you of changes that will be made to your Nixplay account. Starting Monday May 1st, 2023, the current dynamic playlist functionality will no longer be free and will become part of the Nixplay Plus Service (i.e. playlists that automatically update content from third party content providers, such as Google Photos and Dropbox). This means that you will need to upgrade to Nixplay Plus to continue enjoying this feature.

They will allow some usage for free but it is pretty limited

Without subscribing to Nixplay Plus, you will still have access to dynamic playlists but access will be reduced to 1 single dynamic playlist with a max allowance of 100 photos. If you subscribe to Nixplay Plus you will have access to unlimited dynamic playlists with a max allowance of 1,000 photos per playlist.

I found your project which looks like a pretty awesome alternative.

Currently the photos I want to upload to Nixplay are stored locally on my machine. My prior solution was to use rclone to upload them to Google photos and then let Nixplay handle downloading them into the dynamic playlist. To use picsync I would probably upload them to Google photos first with rclone, only to have picsync download and then reupload them to Nixplay. Seems like a lot of unnecessary network traffic.

With this in mind I had a few questions:

  1. Have you ever considered getting picsync functionality by implementing Nixplay as a rsync backend? The big benefit I see is that rclone already supports Google photos as a backend, along with many other cloud storage providers as backend so it could support syncing from many different cloud providers over to Nixplay for free. Big downside is it wouldn't be purpose built for Nixplay/photos usage so it might not be able to support all the functionality you have in picsync.
  2. Is the Nixplay API you are using documented or is it something you reverse engineered?

Thanks for writing this project, excited to see there is already someone else out there that has built an open source way of uploading photos to Nixplay.

andrewjjenkins commented 1 year ago

Hi Anitschke, thanks for your interest!

Very interesting that google photos sync is moving to Nixplay Plus.

  1. Have you ever considered getting picsync functionality by implementing Nixplay as a rsync backend?

No I haven't. I see how that would be a big benefit in your case, and open up more cloud sources, but I think it would be a big change at this point.

  1. Is the Nixplay API you are using documented or is it something you reverse engineered?

Reverse engineered, using "Developer Tools" and doing manual photo syncs. The undocumented API has changed a couple times but not significantly.

Sorry, no great answer, but:

If it is at all helpful for you to start your own project with the Nixplay API here, please go ahead. The actual upload/download logic for google and nixplay is relatively cleanly separated, all the nixplay stuff is here: https://github.com/andrewjjenkins/picsync/tree/master/pkg/nixplay

It's been a vague intention of this (hobby) project to support multiple sources aside from Google Photos. Long ago, this project supported Smugmug but I removed it when I stopped using Smugmug. Adding a "local folder" source would probably not be too difficult. It would require properly abstracting the source and making the logic in syncGoogle.go generic. Maybe we could think about that a bit.

unn commented 1 year ago

Hey @andrewjjenkins I came across your repo in a similar way to @anitschke. Mostly commenting to follow along and say thanks!

anitschke commented 1 year ago

@andrewjjenkins thanks for the quick response and all the details.

rclone is also written in go, so it may not be too much work to port your code over to be a new. When I have little free time to look into it. I'll probably start by just doing some hacking importing from your pkg/nixplay to see how feasible things are. I'll let you know how that goes.

Not sure what you want to do with this issue. I am fine if you close it for now since you answered my questions.