Opus <-> Flickr problem

[quote="Flickr API"][ol][li]http://farm{farm-id}.static.flickr.com/{server-id}/{id}{secret}.jpg[/li]
[li]http://farm{farm-id}.static.flickr.com/{server-id}/{id}
{secret}[mstb].jpg[/li]
[li]http://farm{farm-id}.static.flickr.com/{server-id}/{id}
{o-secret}_o.(jpg|gif|png)[/li][/ol][/quote]
It appears that you are using the third syntax (but not using the farm-id), and Flickr did not return an 'original secret' in its response to your request for a list of photos. I have verified that using the first syntax with the secret and farm-id returned to DOpus by Flickr works with my account. Perhaps this means that DOpus is assuming that the 'original' size is available, but that size is unavailable in my case? Maybe calling flickr.photos.getSizes to verify that the 'original' size is available and reverting to syntax 1 (above) if it is not would work? Disclaimer: I've never used the Flickr API and rarely use Flickr, so the above might be nonsense.

Incidentally, the synchronise attempt is abandoned after the first failed transaction. Would it be more appropriate to retry (perhaps once) and then proceed with the remaining items in the queue? In my case there were 35 photos to download and it only tried the first.

Hmm it's plausible, but I don't understand how the original size could not be available. This represents the actual image that you upload, and as far as I know there's no way to delete that and only keep the other "generated" sizes.

If you go to your flickr account and view one of these images, select the "all sizes" option, does it offer you an original size? If so, what's the URL of that image?

The size list contains square, thumbnail, small, medium and large, but the size named 'large' in this list appears actually to be the original (smaller than the default 'large' size), so you are quite right that it is available.

When using syntax 1 as described before, the image I obtained was the medium size. The link provided by Flickr for the large image is in syntax 3 and ends '_o.jpg', but the 'secret' it uses is the same as for the other image sizes. DOpus isn't substituting any value for {o-secret} when it constructs the corresponding URL: perhaps it needs to fall back on secret if originalsecret is not specified in the Flickr response? Does Flickr only treat access to the original image as privileged if it is larger than its default 'large' size?

Maybe it does, although there is nothing in the API docs about this that I can find. I'll post a message on the developer's list and ask.

The others in this thread having this problem - are your photos the same, in that the original size image you uploaded is actually smaller than the Flickr "large" size of 1024 on the largest size?

Are you able to try uploading a large (> 1024 pixels) image to Flickr and then see if you can download it through Opus successfully?

OK - problem solved (or rather diagnosed). Free Flickr accounts do not allow anyone access to the original size (if it is larger than 'large'), hence the absence of an originalsecret. See Flickr forum post and FAQ entry.

I've tried uploading a larger photo to a free account, and it seems that:
[ul][li]If the original is smaller than 'large', 'large' is unavailable but 'original' is available, using the same secret as any other size.[/li]
[li]If the original is larger than 'large', 'original' is unavailable but 'large' is available.[/li][/ul]It looks like it will be necessary to ask Flickr which sizes are available before downloading, and to use secret if originalsecret is not provided.

(You could also ask or determine if the account is a free one when it is added to DOpus. This is an inferior solution to the current problem, but it would also allow you to avoid initiating uploads exceeding Flickr's per-image limit for free accounts, unless there is a better way of doing this).

I've noticed one other small bug. In the DOpus preferences for a Flickr account, hovering over "User Name" and "Full Name" causes the current values to disappear. If you click to edit them they reappear, so it isn't a big deal, but it would be nice if they'd stay still!

I just wanted to mention that I´m on a free account only. However I only uploaded pictures with and below 800x600 so far - and that should be the maximum size for free accounts as far as I have understood. If you need any data, please tell me which and I´ll send them in a PM to you.

best regards
Lothar

I just tried an upload - fortunately I had synced only two pictures by hand till now. The new one AND the two pics I had synced manually by the search button were successfully added to my flickr account. Upload works, however no sync by download ...

best regards
Lothar

Ok, thanks for your help with this! It definitely seems to be a limitation of free accounts that they don't return an original size, which Opus is assuming will always be there. Hopefully we will get this fixed soon.

You're correct, this is the limitation of free accounts, but, although the original cannot be accessed it is still there and can be accessed when upgrading to Pro account.

I'm not sure if this is relevant, but, many Flickr APIs have been having problems accessing and downloading Original size. This is due to the introduction of a secret code on the Original for security reasons. At one time, even if preferences had been set to stop people downloading your Original, the URL to the Original could easily be worked out by changing the last character to "o", now it can't be done due to the secret code on the URL. Further security precautions have recently been introduce> Here's a quote. (the image file name, incidentally, is the URL on farm1 where the images are kept):

"Image File Naming: We've introduced a few changes around image file names to address privacy concerns and possible caching issues:

"-- Changing the privacy level of any photo ("public" --> "friends", or "friends" --> "family") to will change the image file name. This ensures that any photo truly becomes private.

"-- Replacing a photo will change the image file name.

"-- Rotating a photo will change the image file name.

"In all three instances, this may "break" any photo that has been blogged elsewhere as the image file will have a new URL."

I'm not sure if this could also cause problems with DOpus accessing Originals.

Just a quick post to confirm that the '302' problem has been resolved for me in DOpus 9.0.0.4.

The small hover bug I mentioned is still there, though.

works fine here now as well - many thanks

best regards
Lothar

Does that still happen for you? I can't reproduce it here in 9.0.0.4 but don't remember word of it being fixed. (Either it was fixed but too small to mention or I can't reproduce it here for some other reason.)

[quote="nudel"]Does that still happen for you? I can't reproduce it here in 9.0.0.4 but don't remember word of it being fixed.[/quote]Yes, this still happens for me in 9.0.0.5 - not a big deal, but certainly strange!

Are you using a non-standard theme or anything like that? Or is Windowblinds Compatibility turned on in Opus (try turning it off if so)?

[quote="sch29"]Yes, this still happens for me in 9.0.0.5[/quote]Just in case anyone was unsure, I am referring to the very minor hover issue I identified, not the Flickr icon issue, which has been resolved.

[quote="nudel"]Are you using a non-standard theme or anything like that? Or is Windowblinds Compatibility turned on in Opus (try turning it off if so)?[/quote]No and no.

I get it too, even in 9.0.0.5. It's not a big issue, doesn't adversely effect the performance of DOpus, just puzzling and a very minor irritation like that fly buzzing around one had forgotten about for the last four hours :slight_smile: