thumbnail size wrong

** Upgrade to Gallery 2.0.1 if you haven't already!
** http://gallery.menalto.com/gallery_2.0.1_released

Please fill out the following form and take a look at the linked pages. The more information you supply, the better we can help you.
FAQ:
- What information is required when asking for help in the forums?
http://codex.gallery2.org/index.php/Gallery2:faq#What_information_is_required_when_I_ask_for_help_in_the_forums.3F
- How to enable and use the debug mode of G2?
http://codex.gallery2.org/index.php/Gallery2:faq#How_to_set.2Fuse_Gallery_in_debug_mode.3F
- Known Issues (might explain your problem):
http://codex.gallery2.org/index.php/Gallery2:KnownIssues
- You can copy and paste a lot of the required information from "Site Admin" -> "Maintenance" -> "System Information" if your G2 is up and running.
- Is there a guide for migrating from G1 to G2 available?
http://codex.gallery2.org/index.php/Gallery2:migration

Gallery version (not just "2"):2.0.1
PHP version (e.g. 4.3.11):
PHPInfo Link (see FAQ):
Webserver (e.g. Apache 1.3.33):
Database (e.g. MySql 4.0.11):
Activated toolkits (e.g. NetPbm, GD):
Operating system (e.g. Linux):
Browser (e.g. Firefox 1.0):
--
For migration issues:
G2 URL (optional):stock.modelgraphy.com
G2 version: 2.0.1
G1 URL (optional):
G1 version:
G1 character set:
PHP memory limit:

Album thumbnails show sometimes with wrong dimensions. Height and Width is switched. Likely only when random thumbnail is enabled.

Rowald

I can't believe that and will verify against the source code next I see this. Anyhow, why don't you remove width and height so you will never have this problem? It certainly looks funny ;-)

nope its wrong and its a bug. Its wrong in different browsers even in browser I didn't use for long, so nothing in the cache of those. The last test I started up Firefox, which I didn't use for long and never on this website and it showed stretched thumbnails. If one looks into the code its wrong, height and width is swapped.

we explicitely define the height and width of all photos, videos, ... elements in g2 in the XHTML sourcecode since page rendering can start immediately if the dimensions of all elements are known.
else, you'd have to wait until all elements are downloaded and the page would change a little bit after each downloaded element.

the issue in question is already known / discussed in another topic.

i've just looked at the randomhighlight module code and it's correct. and i'm not sure, but i might have found the bug.

please open modules/randomhighlight/module.inc
replace

	    $ret = GalleryCoreApi::expireDerivativeTreeBySourceIds(array($thumbnail->getId()));
	    if ($ret->isError()) {
		GalleryCoreApi::releaseLocks($lockId);
		return $ret->wrap(__FILE__, __LINE__);
	    }[/code[
with

[code]
	    $ret = $thumbnail->expireCache();
	    if ($ret->isError()) {
		return $ret->wrap(__FILE__, __LINE__);
	    }
	    $ret = GalleryCoreApi::expireDerivativeTreeBySourceIds(array($thumbnail->getId()));
	    if ($ret->isError()) {
		GalleryCoreApi::releaseLocks($lockId);
		return $ret->wrap(__FILE__, __LINE__);
	    }

and then set the randomhighlight delay considerably low such that it changes a few times.
is it fixed?

ok, the above change is nonsense. i found out that this is already covered with $thumbnail->save();

but there are a couple of scenarios where we could end up with distorted random highlight thumbnails.

the reason is not that we cache the dimensions.
the reason is that we check and replace the randomhighlight on ShowItem and on DownloadItem requests.
ShowItem is the HTML page that we generate
DownloadItem is the actual <img src="here"> address of the thumbnail.

so if the randomhighlight delay is set to 0, then we choose in showItem a new random highlight thumbnail and a few milliseconds later we choose yet another thumbnail in the downloadItem request. the first could be landscape the second could be portrait, thus the portrait is displayed, but the html has hardcoded the dimensions of the landscape thumbnail.

another case where this could be a problem:
- randomhighlight delay: any
- showItem request is 1 ms before the delay expires, downloadItem is 1 ms after the delay expiration -> different thumbnails, possibly different dimensions

yet another case:
- showitem has begun outputting html but hasn't finished yet. browser receives the page and already calls downloaditem.
due to a current bug in g2 we commit the db transaction only at the very end of showitem but release the lock already right after the save() call. thus, we still have the old thumbnail data in the database when the downloaditem requests loads the thumbnail. thus the downloaditem request would could choose another thumbnail, since the selection is randomly.
- we're fixing this bug soon.

solution:
- a simple solution would be to only change the randomhighlight on showItem requests. i guess we'll do that.
in onLoad, if it's a downloadItem request, only replace the thumbnail if the current thumbnail is private and the user doesn't have permission to see it

fixed in cvs.
get tomorrows nightly snapshot to fix your g2.

i don't know what you're referring to.
this fixes only the randomhighlight bug.
please open a new topic if it's totally unrelated to randomhighlights.

if these 3 items are albums and if you are using the randomhighlight module, then it's solved.
if not, then it's something else that i haven't seen yet. and you'd have to create a new topic and supply more information.

Hi...

I tried to make a "rebuild thumbs/rezised"... and that seems to do the trick...
I have been using the square thumb plug-in, don't know why, standart installation... i think..

But there have been some pictures the didn't have the correct information.. they had the square infomation..
thx..

hemsoe

BTW ... problem persists in 2.0.2

ohh ... it was just a hint for you guys

thanks