Closed rc-gr closed 10 months ago
@rc-gr The reason it works with the collection API is, because it is able to fallback to the collection thumbnail.
The clipboard method doesn't have it.
Both use the detail API in the same way now through #33 and were basically too before that.
The request is attempted 3 times with an exponential timeout.
The detail API is just a bit finicky and doesn't handle large loads well.
Because using aiohttp-retry returns the last request with any http code, you see these logs.
Not sure how you could prevent that except for increasing the timeout even more.
@rc-gr I've increased the max_timeout to 128 seconds and attempts to 8 for the detail API requests. Fetching the metadata using the file method for 1600 images takes 6 to 60 seconds for me and there are no errors even when doing it multiple times in a short time span.
Currently, for the clipboard method, I noticed that a small portion of images would often fail to download. For example, in my last 3 consecutive runs of one of my collection of 157 images, I get these results:
First run (144/157):
Second run (150/157):
Third run (147/157):
I believe incomplete runs like this happen often because even when trying to save the images normally to my collection on Edge, by using the "Save" button on the page of the image, I occasionally run into the "page not found" page instead of the usual (when the images have yet to expire):
However, switching to the API method, with #33 implemented, the program managed to download all the images in one try:
What I'm suggesting here is to somehow allow the program to re-request the retrieval of the images whose responses are malformed like the above, whilst retaining their index (ie. the re-request should not change an image with eg.
0123
to the highest index + 1).Then, for customizability based on each user's tolerance, also provide a way to configure the maximum number of retries to perform the re-request for each of those images in the config file.