Closed chid closed 10 years ago
I previously switched it from /o/ to /k/ because I was given many examples where /k/ returned the highest-res version.
The next step is for the thread to grab the text on the photo's page to know what the highest-res abbreviation is and grab that instead. It'll slow down the ripper but will resolve this issue permanently.
I've looked into flickr's API and couldn't find an answer there.
That would make sense I suppose. Alternatively just get a size request from both /o/ and /k/ and just get the larger one.
I corrected this in the new iteration of the ripper.
Repo: rip3 File: SiteFlickr.py#L116
It seems like it makes sense to cache cookies from the login.