Uploads and recently uploaded images (which are stored on f.imagehost.org) should be unaffected and continue to work as normal.

Update: the server OS was reinstalled, but it was the wrong version (as the server has loads of RAM, installing a 32-bit OS doesn’t make sense). Unfortunately this is going to delay things some further.

Update 2: Done! While there are still lots of little things (mostly cron jobs) left to set up, the server is hosting files again! Actually once the server came back online (hours ago) I had already hacked up a quick fix to have the other (working) server host the affected files, but this kind of overloaded that server a lot. I figured it was better to have the images load slowly than not at all. But from this moment on speeds should improve as the original server is now taking over the job again.

Update: unfortunately it looks like the system drive of the server will need to be replaced. This means even more down time unfortunately, as it’s going to take some time to get the OS reconfigured again after my provider reinstalls it. No data should be lost however as the drive isn’t completely gone (plus there are backups on other servers). In the mean while I’m going to try to get the main site back online first, using the server that is currently working.

Update 2: seems like when my provider mentioned a reinstall was necessary, they didn’t meant it needed to be done right away and that the system wasn’t booting – it is. So for a short while all of ImageHost.org should be online (pretty much) until the drive will be replaced in a few hours (after which a, b, c, d & g.imagehost.org will be temporary offline until the OS is reconfigured).

These new limits should hardly bother anyone wanting to use ImageHost to hotlink to an avatar or signature, but will prevent users from hotlinking to say, their wallpaper collection. You can of course still upload images that go over these limits, but you will need to use thumbnail or text links instead.

I realize there may be users who just want to share their images and don’t know or can’t be bothered with resizing those images to acceptible sizes, so I’ve added a resize feature to my “to do” list. Once this feature is done, you can have ImageHost.org resize the images to acceptible size after upload for you. Unfortunately I can not give an ETA on this feature though.

Update March 13: It seems a pretty major bug caused hotlinking to images of any size or resolution to be not allowed, which confused one important ImageHost.org user (my mother) a lot. This bug has now been fixed – I apologize for any inconvinience caused. In addition I’ve upped the limits a bit (500 KB & 1600×16000 pixels), so only considerably large images will not be eligable for hotlinking.

Update March 23: Received some complaints, hotlinking is currently back to old limits again.

The current problem with performance mainly lies into finding out how to properly balance new uploads between the two servers used to serve the more than 3 million files that have been uploaded so far. Right now the server to which files are being uploaded to is hardcoded. I’ve got some ideas about how to have the scripts make the choice between servers more intelligently.

Unfortunately I don’t have the opportunity to make major changes to the scripts in the past few weeks. It’s not that I don’t have the time – I got lots actually, but I recently moved and my broadband connection is yet to be reconnected. This makes doing any kind of development frustrating for me.

The time I have now does allow me to think about the future of ImageHost.org. When I relaunched the site last year, I expanded the rules considerably and enabled everyone to upload any kind of file, effectively making the site a hybrid between an image host and a file host (like RapidShare/MegaUpload).

Most people don’t seem to pick up on this change however. The vast majority (95%) of files uploaded each day are the common web image formats JPG, PNG and GIF. When non-image files are uploaded, they tend to contain copyrighted material. And due to the nature of ZIP and RAR files, plus the ability to add passwords, it’s pretty hard to actually find out if files violate the Terms of Service unless someone reports them.

For this reason I’ve decided to go “back to the roots”. In the next major revision of the scripts (hopefully due in a few months), you will only be able to upload common web image formats. If you liked the ability to upload non-image files, rest assured the change won’t go into effect for some time and when it does won’t affect files already uploaded. But based on the statistics of what kind of files are uploaded, I don’t think many people will complain.

Last, I keep receiving requests for two features: the ability to delete the files you uploaded and some kind of registration system so that you can see which files you’ve uploaded from other PC or in case you lose the ImageHost.org “cookie” (which is required for the Gallery page feature). These features have been on my “to do” list for a while, but for the reasons I mentioned earlier I unfortunately can’t promise to implement them very soon.

Anyway, thanks for using ImageHost.org and a Happy New Year to you!

To combat this problem, I’ve put the new server I talked about in an earlier post (identifiable by the upload url e.imagehost.org) in to active duty immediately. The only problem is that the method my scripts use to transfer new uploads to this server (which unfortunately are still coming from the overloaded server) isn’t terribly reliable, so some uploads may fail. If that happens, just try again.

I apologize for the inconvinience. I have ideas on how these various issues can be addressed and handled better in the future, but unfortunately this will require further script development so it will probably not be ready soon enough to be of any help right now.

Update: above text applied to Friday, November 14. Site performance should now be back to normal.

For this reason I’ve added a “whitelist” of sites where even if you hotlink to files & cause lots of datatransfer, the image won’t get disabled. Sites in the whitelist include Digg (of course), MySpace, Facebook, Orkut, Slashdot, LinkedIn and eBay, amonst others. If you still find a file is being disabled for using to much bandwidth when you are hotlinking from a major site (with millions of visitors), drop me a line and I’ll add it to the list if I find the site suitable. Btw, if you use thumbnails or text links to link to your files then bandwidth limits do not apply.

I’ve also fixed a rather major bug in the bandwidth limit rules, or rather the data the bandwidth limits act upon. If you upload a file to ImageHost.org, it has a hourly bandwidth limit of 300MB per hour. If it goes over this limit in a single hour, the file is deleted. This limit however only applies if you are hotlinking to the file: if you properly use thumbnails or text links to link back to ImageHost.org, the file is not subject to this limit and could potentially use much more bandwidth: even gigabytes of bandwidth per hour is allowed that way.

There was however a problem with the logic my scripts used to determine if a file is solely being hotlinked to, or if thumbnails or text links are used to link to it. I won’t go into details, but basically the logic only worked properly for data collected earlier, not for data collected in the past hour. So if a large new file (say a 100MB ZIP file) was uploaded an downloaded a few times (3-4 times or more), it would go over the 300MB hourly limit. However because the “hotlinking logic” was not working, the file would get deleted by the bandwidth limit script – even if you had properly used text links to link to the file. Fortunately this problem has now been fixed.