Incremental Indexing about gphotos-sync

[gilesknap]

Hi @ido-ran.

You may be right. I see your workarounds as follows:

• set number of threads to very low (1 might be good) - this will slow down your downloads to spread the load on quota
• use date ranges to do your photos in chunkss
• once you are synced all is good because the incremental backup will only search for photos since the last backup time.

(use --help to see how to set those options)

[ido-ran]

Hi,
Thank you for the quick response.
I was quick the assume I'll run out of quote but at the end I've used 5.18k out of the 10k.

I would like to know what you think about changing the script to store the last page_token so it will be able to pickup from where it left off.

I agree that for most part once the full scan has complete search by date will produce much smaller results but every once in a while I do either upload photos without date, which usually end up in 1970 or I upload old photos which the search by date will not find.

[gilesknap]

Yep - you need to use --flush-index occasionally if older photos have been uploaded. I should probably make that clear in the docs.

re: keeping the page_token. I would have thought that it has a reasonably short expiry but I could be wrong.

[ido-ran]

I have photo frame project that also download photos from Google Photos and I've noticed I can use page_token even a day later. I'll give it a go and will let you know.
I am currently get to about 8.2k requests when the quota is 10k, I also run it close to midnight so I use some quota of today and some tomorrow.
Storing the page_token should also allow the script to pickup where it left off when stopping the indexing in the middle, that will also be a useful feature.

[ido-ran]

One last question, can I use --rescan insetad of --flush-index?
It seems like rescan start to scan from scratch but just doesn't drop the database.

[gilesknap]

Yes you are right that is a better option!

[gilesknap]

I believe this issue is completed - closing