Worth opening a separate post for.

This is not about the flickr-api being slow or even that it has errors- just the way the program handles this in my attempt to run it unattended.

The program will occasionally hit HTTP Server Error 500 which forces it to close. Thankfully, upon restart it will check to see if a file has already been downloaded. The issue is how this is handled.

It seems a working connection to the Flickr website is required to check files. I'm guessing it starts the download/connection process with the latest photoset, and then only check if it exists locally.

This leaves the program liable to fail at the checking stage due to API errors, making it very hard to reach the resume download stage with large photosets, as well as being slow.

For example - I am on 17,402 images. On average I'm going to guess it can check 1.6 photos a second, which means 3 hours of no API issues before it can resume downloading.

Using https://github.com/chebum/Supervisor to automatically restart the program, I have left it running all day just to see it stuck checking files.