Max Image Dimensions Issue

[Pete]

Hi guys

I've encountered what I think is an error with Image fields.

Change the settings of your image field so that the max width is 1600 and the max height is 1200. Upload a picture in landscape orientation that's larger than this and it works, Upload a picture in portrait orientation that's larger than 1200 and it breaks.

So for me it's failing with errors when uploading large portrait-orientation images.

Can anyone else reproduce this? Feel free to change those values to smaller ones if you've not got any huge images to hand

[ryan]

I couldn't seem to duplicate here. I changed my max width to 800 and max height to 600, then uploaded a portrait orientation image of 734 pixels in height. It seemed to work as it should. Can you think of anything else I should try? I know that sometimes PHP's image functions can't handle some images I've thrown at it (high DPI images).

[apeisa]

So for me it's failing with errors when uploading large portrait-orientation images.

What kind of errors it provides?

[Pete]

I wonder if it's because some of the filenames have dimensions in them already before uploading? Doesn't explain the alien image not uploading for me though.

Attached are three that wouldn't upload (these are original size and original filenames).

I'll try increasing memory and so on on my test server later as that might be it if these work for you.

[ryan]

Nice images. Though I couldn't reproduce any errors. They all uploaded and resized just fine for me (still using the max 800x600 setting).  It is possible you are running up against a memory limit as you mentioned, though these are all pretty small images in terms of file size (300k, though jpeg compressed). I would make sure your PHP has at least 128m allocated to it. Also take a look at your phpinfo() and see what GD version it has, just in case there are any known issues there.

[Pete]

Yup, I think it must be memory related. I'll change some setting in the morning.

Cheers for checking Ryan - it always helps if someone else tests it even if it's not an issue that can be reproduced.

[Pete]

Okay, so it's not memory-related. Increased memory limit for PHP to 512mb and increased max filesize and post time etc.

It's very odd indeed. I've managed to get it working on my live server - didn't have to change a thing.

My local server is XAMPP on Windows though so it's a totally different environment anyway.

The error message I get from trying to upload one of the bizarrely-affected images is:

Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120

Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120

Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120

Which points to permissions being the issue. Any idea why it would be having trouble on image permissions for some images and not others? I'm just going to hazard a guess that it works on my live server as it's a Linux box whereas on XAMPP on Windows PHP is having trouble with Windows permissions (not that there's any reason it should). I even went as far as saving one of the images in Photoshop then did a Save for Web and gave it a totally different name with no luck.

Oh, and I updated XAMPP to the latest version too so new version of the GD library theoretically, but the errors I get above aren't to do with GD anyway I don't think.

EDIT: Also worth noting - I've checked the permissions on the file before uploading and they're fine. I also noticed that it DOES manage to create the newly sized image, but then fails to create a thumbnail - so I've got an image called ufoam_alien222.0x1200.jpg but no thumbnail.

Looking at it it seems that it's only images that larger than the max width and height I've set so I wonder if we're getting some sort of weird Windows-only error here?

[Pete]

Just a note to say that whilst I've been trying to solve this, I've noted a few things in PW's code.

1) Wherever chmod() is used, it's inconsistent as to whether there is an @ before it (so @chmod() )  or not. Guess all occurences should be @chmod to avoid possible issues in Windows???

2) ImageFilledRectangle in wire/core/ImageSizer.php should be lowercase, so imagefilledrectangle (2 occurences here).

Minor things I know, but thought I'd bring them up whilst I'm hunting for a solution

[ryan]

Thanks I'm correcting the case issue. As for the "@" in front of the chmod, that just suppresses warning messages, so not sure it would matter here. Using it is just an old habit that pops up every once in awhile, though I generally prefer not to. Then again, I don't use Windows – does it account for something different in Windows?

I'll adjust the function name case now. Not sure why I've got UCWords case on those! oops.

Can you confirm that this error definitely appears to have something to do with the image size or resolution? Do you run into any issues on smaller images? If not, do you know about where the cutoff is?

[Pete]

I thought the @ might be an issue as chmod won't have any affect on Windows so wasn't sure it would cause an issue or not but it doesn't (or a lot of gallery scripts would struggle on Windows!).

It's definitely something that only affects images that are being resized - it seems to corrupt the original image now that I'm looking into it further, but generates the resized version just fine. I'm basically going to put en exit; command in the ImageResize file after every action it performs on the original file one by one and see if I can pinpoint exactly where it causes the issue.

[ryan]

Pete, thanks for your assistance in figuring this out. It might be useful to get a debug backtrace from the point where that error is occurring. If you want, try adding this at the end of the getImageInfo() function in /wire/core/Pageimage.php (before the last line, return statement):

if($info === false) throw new WireException('for backtrace'); 

You'll also need $config->debug (debug mode) to be on. If you can paste in the backtrace here, I might be able to get a better sense of exactly where it's running into trouble.

Also, we were originally talking about this having something to do with portrait vs. landscape orientation of the photo. I'm guessing that's no longer the case, but just wanted to double check?

[Pete]

No worries, I'll try that shortly.

It seems to just be any image that needs to be resized, whether portrait or landscape. I careated some landscape and portrait images in Photoshop (big green rectangles) and saved them in jpeg, png and gif formats and it happens to all of them.

Also it seems that if I stop execution at the end of the ImageSizer resize() function just before it returns, the images it's created up to that point are fine, so it's at some point after this - I think resized images go through this twice maybe?

Anyway, I'll try your code and see if it helps pin this down.

[Pete]

Aaaand, we now have a backtrace

Here's the errors at the top of the screen:

Warning: rename(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.1600x0.jpg,C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.rename]: Access is denied. (code: 5) in C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldImage\InputfieldImage.module on line 43

Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 115

Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 121

and ehre's the backtrace:

TemplateFile: for backtrace

#0 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldImage\InputfieldImage.module(44): Pageimage->getImageInfo(true)
#1 [internal function]: InputfieldImage->___fileAdded(Object(Pageimage))
#2 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#3 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('fileAdded', Array)
#4 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(130): Wire->__call('fileAdded', Array)
#5 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(130): InputfieldImage->fileAdded(Object(Pageimage))
#6 [internal function]: InputfieldFile->___processInputAddFile('jlandscape.jpg')
#7 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#8 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInputAdd...', Array)
#9 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(185): Wire->__call('processInputAdd...', Array)
#10 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(185): InputfieldImage->processInputAddFile('jlandscape.jpg')
#11 [internal function]: InputfieldFile->___processInput(Object(WireInputData))
#12 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#13 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array)
#14 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): Wire->__call('processInput', Array)
#15 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): InputfieldImage->processInput(Object(WireInputData))
#16 [internal function]: InputfieldWrapper->___processInput(Object(WireInputData))
#17 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#18 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array)
#19 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): Wire->__call('processInput', Array)
#20 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): InputfieldWrapper->processInput(Object(WireInputData))
#21 [internal function]: InputfieldWrapper->___processInput(Object(WireInputData))
#22 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#23 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array)
#24 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(579): Wire->__call('processInput', Array)
#25 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(579): InputfieldForm->processInput(Object(WireInputData))
#26 [internal function]: ProcessPageEdit->___processInput(Object(InputfieldForm))
#27 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#28 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array)
#29 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(147): Wire->__call('processInput', Array)
#30 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(147): ProcessPageEdit->processInput(Object(InputfieldForm))
#31 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(94): ProcessPageEdit->processSave()
#32 [internal function]: ProcessPageEdit->___execute()
#33 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#34 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array)
#35 C:\xampp\htdocs\sc11\wire\core\ProcessController.php(194): Wire->__call('execute', Array)
#36 C:\xampp\htdocs\sc11\wire\core\ProcessController.php(194): ProcessPageEdit->execute()
#37 [internal function]: ProcessController->___execute()
#38 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#39 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array)
#40 C:\xampp\htdocs\sc11\wire\core\admin.php(42): Wire->__call('execute', Array)
#41 C:\xampp\htdocs\sc11\wire\core\admin.php(42): ProcessController->execute()
#42 C:\xampp\htdocs\sc11\site\templates-admin\controller.php(13): require('C:\xampp\htdocs...')
#43 C:\xampp\htdocs\sc11\site\templates\admin.php(13): require('C:\xampp\htdocs...')
#44 C:\xampp\htdocs\sc11\wire\core\TemplateFile.php(88): require('C:\xampp\htdocs...')
#45 [internal function]: TemplateFile->___render()
#46 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#47 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('render', Array)
#48 C:\xampp\htdocs\sc11\wire\modules\PageRender.module(194): Wire->__call('render', Array)
#49 C:\xampp\htdocs\sc11\wire\modules\PageRender.module(194): TemplateFile->render()
#50 [internal function]: PageRender->___renderPage(Object(HookEvent))
#51 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#52 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('renderPage', Array)
#53 C:\xampp\htdocs\sc11\wire\core\Wire.php(289): Wire->__call('renderPage', Array)
#54 C:\xampp\htdocs\sc11\wire\core\Wire.php(289): PageRender->renderPage(Object(HookEvent))
#55 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('render', Array)
#56 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageView.module(73): Wire->__call('render', Array)
#57 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageView.module(73): Page->render()
#58 [internal function]: ProcessPageView->___execute()
#59 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array)
#60 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array)
#61 C:\xampp\htdocs\sc11\index.php(170): Wire->__call('execute', Array)
#62 C:\xampp\htdocs\sc11\index.php(170): ProcessPageView->execute()
#63 {main}

I think the newest comment here might hold the answer for Windows: http://php.net/manual/en/function.rename.php

I suspect that rather than sleep() as that comment suggests, simply delete the original file before renaming the other file to it.

[Pete]

Hmm... so there is an issue overwriting or deleting the original file it seems.

What I did based on the above error was change InputfieldImage.module so that the ___fileadded function looks like this:

protected function ___fileAdded(Pagefile $pagefile) {

	$filename = $pagefile->filename; 
	$pagefile2 = null;

	if($this->maxWidth && $pagefile->width > $this->maxWidth) {
		$pagefile2 = $pagefile->width($this->maxWidth); 
		rename($pagefile->filename, $pagefile->filename . '1');
		unlink($pagefile->filename . '1');
		rename($pagefile2->filename, $pagefile->filename); 
		$pagefile->getImageInfo(true); // force it to reload it's dimensions
	}

	if($this->maxHeight && $pagefile->height > $this->maxHeight) {
		$pagefile2 = $pagefile->height($this->maxHeight); 
		rename($pagefile->filename, $pagefile->filename . '1');
		unlink($pagefile->filename . '1');
		rename($pagefile2->filename, $pagefile->filename); 
		$pagefile->getImageInfo(true); 
	}

	if($pagefile2) {
		$this->message("Resized '{$pagefile->basename}' to {$pagefile->width}x{$pagefile->height} fit within max dimensions of {$this->maxWidth}x{$this->maxHeight}"); 
	}

	parent::___fileAdded($pagefile); 

}

What I've effectively done is renamed the original image before renaming the resized image to the original name of the original image (with me so far? ). What it still refuses to do is delete the now-renamed original image and cites permissions as the issue. It's very weird because I've triple-checked permissions on the whole web folder on my hard drive so I know they're fine.

I'll continue investigating - I think it'll be easier now I'm looking in the right file at last!

EDIT: Okay, so I changed the function again to the one below:

protected function ___fileAdded(Pagefile $pagefile) {

	$filename = $pagefile->filename; 
	$pagefile2 = null;

	if($this->maxWidth && $pagefile->width > $this->maxWidth) {
		$pagefile2 = $pagefile->width($this->maxWidth); 
		rename($pagefile->filename, $pagefile->filename . '1');
		unlink($pagefile->filename . '1');
		rename($pagefile2->filename, $pagefile->filename . '2'); 
		unlink($pagefile->filename . '2');
		$pagefile->getImageInfo(true); // force it to reload it's dimensions
	}

	if($this->maxHeight && $pagefile->height > $this->maxHeight) {
		$pagefile2 = $pagefile->height($this->maxHeight); 
		rename($pagefile->filename, $pagefile->filename . '1');
		unlink($pagefile->filename . '1');
		rename($pagefile2->filename, $pagefile->filename . '2'); 
		unlink($pagefile->filename . '2');
		$pagefile->getImageInfo(true); 
	}

	if($pagefile2) {
		$this->message("Resized '{$pagefile->basename}' to {$pagefile->width}x{$pagefile->height} fit within max dimensions of {$this->maxWidth}x{$this->maxHeight}"); 
	}

	parent::___fileAdded($pagefile); 

}

Essentially this is now creating another copy of the file and then unlinking it. I wanted to see if the script could at least delete the image it created and it can, it can also rename the original image. It just cannot delete it for some reason

I must have checked all my folder permissions a dozen times now as well :(

[ryan]

Pete, thanks for continuing to try and debug this. Admittedly, I'm at a loss so far–it seems pretty bizarre that it's not working. Though it's also the end of the day here and my mind is mush. I almost wonder if there is some issue in the version of PHP you are running (perhaps combined with Windows), or if there is some PHP setting that's interfering with our file operations. Can you take a look at your phpinfo() and see what PHP version you've got? Then we can look in the changelog and see if there was some version-specific issue. While you are there, check to make sure you don't have any safe_mode or open_basedir restrictions in effect too, just in case.

[Pete]

I think I've pretty much given up on this one as "a Windows thing".

I used XAMPP 1.7.4 and upgraded it to 1.7.5 to try and overcome this, so the versions of PHP et al are:

Windows (1.7.4):

    Apache (2.2.17)

    MySQL (5.5.8)

    PHP (5.3.5)

Windows (1.7.5-beta5):

    Apache (2.2.19)

    MySQL (5.5.15)

    PHP (5.3.7)

Pretty sure it's not the versions to blame though as if you Google "PHP Windows unlink" and "PHP Windows rename" you'll find a raft of issues dating back to the dawn of time (well, 2003 was the furthest back I remember seeing it).

Apparently, though I don't know how accurate this is, rename essentially just uses PHP's copy() function and then uses unlink() to delete the original so someone on the web has suggested the problem is in unlink() on Windows.

The bit that makes it impossible to resolve is that if I leave it long enough the file disappears (the original image file that's aborted halfway through the rename process it seems). What you get is the resized large version of the file - so if it's an over-sizes portrait image you get the 1200px high version in my case. PW then tries to rename this over the original which is where it fails, so you end up with the 1200px high version still in the folder and a corrupted (or rather broken - you can't open the image) "original" filename version.

Just to satisfy my curiosity ryan, is there any way we can change the code just as a test so that if an image needs resizing, the image that's been uploaded never gets moved to the page's folder in the first place? I.e., is there a quick way to test if we can get around this by not copying the original uploaded file to the folder if it needs resizing? The reason I ask is that PHP on Windows seems fine and dandy when it's dealing with copied images, or even original image files that don't need to be resized but have been copied to the page's folder, but it just falls over when it tries to manipulate the original. So in my sleep-deprived brain, it would check the uploaded file's dimensions and, if it needs resizing create a new image and copy that across to the page's folder with the original filename, else if it doesn't need resizing copy it over to the page's folder as it is.

Also, due to tiredness, I realise I've been saying this is PHP on Windows, whereas actually XAMPP is still Apache, just sitting on a Windows machine which I think is where it's hitting some weird permissions issues. I did even try setting the entire website folder and temp folder so the "Everyone" user has full access to do anything they like which didn't help, so I don't know whether it is so much a permissions issue but rather a file locking issue on the Windows file system.

Anyway, my head hurts. If it can't be resolved then I'll just leave copying this site across until I've uploaded PW to the actual server (inside a dev folder) where it seems quite happy to perform this simple function It's just stupid as it just seems Windows likes to randomly lock files for a random period randomly

[ryan]

Thanks for your thorough investigation into this issue. I agree it is a strange one. If you find some way we can bypass it, I'll be glad to update PW's code. Though I don't currently have a way of testing this issue (running on different platforms).

Just to satisfy my curiosity ryan, is there any way we can change the code just as a test so that if an image needs resizing, the image that's been uploaded never gets moved to the page's folder in the first place? I.e., is there a quick way to test if we can get around this by not copying the original uploaded file to the folder if it needs resizing?

This would be tricky because the process that handles uploads is completely different from the process that handles image manipulations. ProcessWire expects a file to be part of it's file system before it starts manipulating it. So while I'm sure it's possible, it's not a straightforward thing because it would be an architectural change. I'm wary of architectural changes to support an obscure bug in Windows.

Here's something I found in the user comments on the unlink documentation page at PHP.net that has me wondering:

Under Windows System and Apache, denied access to file is an usual error to unlink file.

To delete file you must to change file's owner.

An example:

<?php 
chown($TempDirectory."/".$FileName,666); //Insert an Invalid UserId to set to Nobody Owner; 666 is my standard for "Nobody" 
unlink($TempDirectory."/".$FileName); 

Doesn't exactly sound like a cross-platform compatible solution, but maybe a hack to make it work in Windows. If you find something like this works, let me know and we can always make it perform this action if it detects it's in Windows (or perhaps with a config option).

[Pete]

I know what you mean - to be honest without a proper Windows server (IIS with PHP and mySQL) to test this on it could still just be an issue on my XAMPP installation/some weird permissions issue/only an issue on my machine It's only a development platform after all and not designed as a proper server platform, so yeah, not a good idea to start radically re-thinking how files are handled, especially as the way they're handled presently is perfectly good OOPHP with one class for uploads and another one for image transformations.

I tested that bit of code and it didn't work unfortunately, but to be honest it's really not a big deal for me and I've wasted enough time trying to solve it now I reckon

I think the solution for me is to just set the galleries up, finish the rest of the site off, upload it to the live server in a /dev folder or something and upload the gallery images then when it's on a real server.

It's certainly not worth more hours of head-scratching that I could have spent on porting the rest of the site across to PW.

Thanks for the assistance though ryan - much appreciated and at the very least I've learned another bit of code which I can use to track bugs in PW, not to mention I know some classes a lot better now!

[Pete]

Okay, just for poops and giggles I decided that since I have two hard drives in my laptop I'd install XAMPP on the other hard drive and test this issue once again.

Resizing now works fine Thing is, I could have sworn I tried this already!

Oh well, I need to do some testing this evening, but if I track down what the exact cause is I'll let you know - I am wondering if it's because my main hard drive is an SSD and it's trying to write and then overwrite the same file so fast it's failing there. It makes some sense in my head anyway.

[ryan]

That's bizarre. I wouldn't think an SSD drive would make any difference, but who knows. I'm just glad to hear it's started working for you.

[Pete]

Cheers ryan

Just to confirm, I've now got it working fine on my SSD too, so I'm chalking it up to a broken XAMPP installation. I think when I reinstalled XAMPP the last few times I tried to fix this, I must have copied over some apache settings or bad file permissions from the broken installation.

Works now, so it's absolutely nothing to do with PW (which we knew) but in case anyone encounters anything like this in future on Windows then it might well be your XAMPP installation.

Headache over

[apeisa]

I used to use xampp, but got really tired of all tiny problems I had with it. Vanilla apache / php / mysql installation was a breeze (I think it used to be problematic, but it's not anymore). Hardest part was to download right executable of PHP: http://windows.php.net/download/ (read the left sidebar!).

[Pete]

That link scared me :-\ 

Thanks for the link though - it probably would be much better if I took some time to learn how to do this properly rather than relying on a sometimes-buggy setup.

[Pete]

Ah.

I'm an idiot. I blamed my tools, but it turns out I was a tool (British slang for "idiot").

I've had Acronis non-stop backup software monitoring that folder, so as soon as the file was uploaded the non-stop backup was copying the file to my backup location whilst PW was busy trying to resize it!

I feel so stupid Oh well, turned off non-stop backup as I'm happy enough with my twice-daily full backups (a morning's work isn't as bad to lose as 3 months!).

After all that, I can't believe I didn't think of this... oh well!

And this definitely concludes this epic thread now

[apeisa]

The most epic thread award for you Pete!

Back to topic: it is always relief to understand why something happened - no matter how silly the reason is.