FIXED: Picture Error with Tiger and Bunny


Back to topics list
[post:507#4959]
Ggultra2764

04/03/2011 12:20 AM

Reviews: 2354
Posts: 568

I was making a series listing for the new Spring 2011 anime, Tiger and Bunny, and ran into this snag. Any attempt I make to attach a picture for it either won't display on the browser (Firefox) or you just get a blank box indicating a broken picture (Chrome and Internet Explorer). Trying to right-click and check out the picture by itself on another web page results in a 500 Internal Server Error.

[post:507#4960]
Stretch

04/03/2011 08:45 AM

Reviews: 2065
Posts: 1345

Neither myself nor kay marie could add an image to at least two different pages a couple days ago. This will be a problem when a wave of new Spring series arrives in a week or two.

Edited on 04/03/2011 09:00 AM.

[post:507#4962]
Devil Doll

04/03/2011 12:15 PM

Reviews: 365
Posts: 1574

The series image is taken from

http://images-anime.mikomi.org/images/sized/400/600/2441.jpg?1301845770

which is a separate domain for images. The "sized" part must be the URL trickery that triggers the image resizer to be activated (shrinking the image to a maximum of 400x600px), the "1301845770" part is the time stamp of the image (so that several versions can be stored on the server).

But that's not different from other anime images that are already uploaded (these can still be displayed correctly), so taking these from the separate domain and running them though the resizer apparently isn't the cause of the problem (i. e. neither the domain nor the resizer is broken per se). Which leaves the image itself as the likely cause, or to be more precise - the uploading procedure of said image. My guess is that this upload procedure is broken and creates an image that would cause the resizer to run into an unexpected situation, thus causing the HTTP-500.

A wild guess: Could it be that the file system for storing images on the server has run full so that the uploader now creates empty files there (instead of rejecting the upload with an error message)? Resizing these could give the resizer a hard time as they would not have a correct file format for JPEG. (Writing this, I tried uploading PNG and GIF images just in case, but the effect is the same for all three file formats.)

E-mail to Rebecca is on its way.

Edited on 04/03/2011 12:24 PM.

[post:507#4963]
Devil Doll

04/03/2011 02:53 PM

Reviews: 365
Posts: 1574

Looks like Rebecca fixed the issue already.

[post:507#4966]
Rebecca

04/03/2011 06:27 PM

Reviews: 23
Posts: 772

The short of it is: The problem has been fixed.

The problem was that, somehow, the script had been set non-executable. Probably related to some changes I made to my backup regimen. (I now store all of the installs to my web sites in a Dropbox synced directory.)

But let me explain a bit how images work here. It's not really obvious, in large part because it's evolved over time. When you upload an image it gets put here:

http://images-anime.mikomi.org/images/series/2441

The images domain is used in order to reduce the amount of data you send when you request an image. You won't send cookies, this way. The 2441 is the series ID.

In a web page on the site, you'll instead see links like this:

http://images-anime.mikomi.org/images/sized/400/600/2441.jpg?1301845770

Like all URLs served off of images-anime.mikomi.org, this is a static file on disk. If the file referenced by the URL doesn't exist, it's generated on for the request and placed on disk so future requests don't need to use the script. The final part, is a timestamp that's complete ignored by the server and is not part of the filename. It can be anything... you can add anything to it and it will have no effect. It exists only to force browsers to use the right version of the image when it's updated.

[post:507#4967]
Devil Doll

04/03/2011 07:23 PM

Reviews: 365
Posts: 1574

So said script (that creates the static file for the resized image) is kind of a 404-handler for the image directory?

[post:507#4976]
Rebecca

04/04/2011 02:35 PM

Reviews: 23
Posts: 772

Specifically? No, it's triggered by a rewrite rule (below). This is why if you specify a series id that doesn't exist you will actually get a 404.

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-s

RewriteCond %{DOCUMENT_ROOT}images/series/$3 -s

RewriteRule ^/images/sized/([^/]+)/([^/]+)/(.+)\.([A-Za-z]+)$ /image_manip.cgi?$1,$2,images/series/$3,!resize,$4,images/sized/$1/$2/$3.$4,!store [L,NS]

The first condition says that the file doesn't exist on disk yet. The second says that the series id -does- exist in the raw images folder.

And the finally we rewrite it into arguments for the script. The script uses a little domain specific language to do it's manipulation.

I used to watermark images that were directly linked from other sites (I just refuse those requests now), and I used this mechanism to add the watermark. It's a simple stack based language.

So to resize, given that $1 is the max width, $2 is the max height, $3 is the series id and $4 is the image type (eg, jpg, gif, png, etc):

$1,$2,images/series/$3,!resize,$4,images/sized/$1/$2/$3.$4,!store

And to add a watermark, given the same arguments:

$1,$2,images/series/$3,!resize,!sizeof,leach_trans.png,!resize,SouthWest,!merge,$4,images/sized/leached/$1/$2/$3.$4,!store

Edited on 04/04/2011 02:36 PM.

Reply to this topic Start a new topic
Back to topics list

Community Anime Reviews

anime mikomi org