What happened to ProductServe images???

[authcode]

Something changed yesterday with the images served from productserve.com because my image manipulation and caching code stopped working. I've managed to restore some functionality by editing the code but now I can only load previously cached images. New images seem to not be loaded by the PHP function "imagecreatefromjpeg".

Anyone care to enlighten us as to what changed yesterday (13/08) on productserve???

[Confuscius]

Hi Steve

I hit a similar issue! I check the image size in php using the getimagesize() function in order to create my own maximum image sizes in html - every request now gets a 403 forbidden from the image server.

I reported this to Adrian yesterday as I was going a bit crazy and he has said that he will investigate with development. I too have recoded so that I do not get thousands of errors in my error log and also if the image size cannot be got then I set it to a standard size with some interesting effects now being shown!

It sounds like they have blocked banned this particular route but I am still a little puzzled as the getimagesize sends an http request so I suggested that they might have an IP ban?

No doubt Adrian will update us soon.

Paul

[authcode]

Thanks for the reply Paul. I'm always dubious when I'm seemingly first to notice such an obvious bug so I spent some time this morning checking it out to make sure it wasn't anything I'd done. Wasn't likely though as my image code has been working fine and untouched for months so it's good (in a way) to hear it's not just me.

Hope this one gets resolved quickly, missing images look even worse that missing products!

[Paul Inman]

Hi guys,

We moved hosting of images to new servers on this date using a new daemon to speed delivery times up and it has service abuse checks in place.

I would suggest using other means and make sure your methods are not likely to trigger an abuse, for example repeat/concurrent request from the same IP.

If you are downloading images to resize them, I would recommend using the merchant Image URL anyway. This will give you a higher res image to work with.

If you are using a caching I would recommend doing this 'on demand' rather than using batch methods.

Hope this helps,
Paul

[authcode]

Thanks Paul (Inman).

Would've appreciated a heads up though, would've saved a lot of my time investigating the problem.

Last time I used merchant image URLs they were full of junk, like 6000x4000 pixel images or animated gifs. AW images seemed like a safer bet, until a few days ago.

I'll make the switch and see what happens, when the feed comes back online after the weekend I suppose.

I don't really understand how repeat/concurrent requests is considered a service abuse though? Surely that's the point of an image server? At least I actually cache those images, I bet the hordes of client users don't.

[Confuscius]

Hi Paul

Thanks for the info - not good news!

The issue is a simple one - there appears to be little control over the quality and image sizes provided by merchant and, to be totally blunt, this leads to a completely amateurish appearance to Shop Window pages that display multiple images.

My particular methodology was to pre-read the image using php to get its size - it is then relatively easy to perform a few calculations to calculate new pixel sizes for display purposes which have a maximum dimension, either width or height. These two numbers are then passed to two Smarty variables and then in the template the image sizes are set to MY definition. The image is then read but the browser displays the results - so no image manipulation. If you could see the difference that this makes to the appearance then you would understand why this is bad news.

Just an example lets say the merchant supplies a picture of a pencil, 20 pixels wide and 200 pixels high. My first attempt was set the width to a standard of say 100px so in the browser we get a new rendering 100px wide and 1000pixels high - complete loss of definition and it looks pathetic. My second approach where the maximum dimension is 100 displays it as supplied.

What ideas have you got for addressing this at your end?

I have one - would it be possible for you to store in the XML two additional pieces of data for every image, its width and height? If you could do this then it would be not too difficult to provide a couple of code changes that would improve ALL Shop Window installations.

Being able to maintain the aspect ratio of all images is fundamental to creating a good looking Shop Window site and at present this does not seem possible by any way that I can think of. Any ideas anyone?

Paul

[authcode]

Well, now the migration is over I've changed my code to use merchant images in place of productserve images and from what I can tell there are even less images available now.

I still don't understand why the productserve server can't cope with the demand? Surely a lot of image loading was anticipated when ShopWindow was designed?

This seems like a massive step backwards.

[kingsib]

Now i just serve the images straight from the images.prod.... url and hope everything works i too was caching them and all html in what i considered to be a server friendly way - i have terrabytes of storage so would download image once and description once and serve it to many users - now the only option left is to let aff window do it all - and the api server seems especially at peak times to fall under the strain.

What would have been better if when we had the phone call about the downtime if we had been told about this - I only just worked it out when our bandwidth usage fell off completely but i suppose now affiliate window can actually see how many times a product / image is requested.

Cheers

***UPDATE***

It seems like affiliatewindow only stop you downloading images if all requests come from one server (abuse of bandwith by one person all well and good if thats what you were doing, but none of us seem to be), i have now got caching back up and running by changing images.productserve.com for images.productserve.com.nyud.net (a free open-source content distribution network (they store the image as long as it's being used)) by doing this I can now manipulate the images and cache/resize on the fly and the best thing is it uses over 400 different client machines to download from the webserver so if one fails or gets blacklisted the others takes over and as a last resort it falls back on the original url which i find happens once in a blue moon. therefore your own usage on images.productserve.com is minimal, and your ip should not get blacklisted by the slightly over sensitive server.

Also being a content distribution network means if all your doing is displaying images the several gigabytes/second of bandwith shows the images far faster than pulling direct from productserve after the 1st image has been loaded.


for more info see http://www.coralcdn.org/


see it in action http://www.ilkleynet.co.uk



seems this broke now as well....