When running the full screen slideshow, it attempts to load the album, then the java application displays an error at the very bottom portion saying "Downloading main failed". This happens on all of my albums on the latest versions of both firefox and IE. I have also tried it on two separate Windows XP computers, both have the latest version of the Java VM installed.
I have also tried optimizing the gallery database (MySQL), deleting the template cache, and deleting the database cache.
----
Gallery URL (optional):
Gallery version:2.0-beta-3 core 0.9.17
Webserver (with version):Apache/2.0.49
Datatabase (with version):mysql 3.23.58
PHP version (eg 4.2.1):PHP/4.3.6
phpinfo URL (optional):
Graphics Toolkit(s):netpbm
Operating system:Fedora Core 2
Web browser/version:firefox/IE (latest)
G1 version (for migration bugs):
Posts: 32509
jonaskuh, Do you use the MS java VM or the sun java VM? It works with sun's VM, don't know about MS.
can you test it with the latest G2 version too (core version 0.9.21)?
http://galleryupdates.jpmullan.com
Posts: 3
I figured out the problem. If you enable hotlinking, the Java client will not be allowed to go directly to the images, causing the full screen slideshow to fail. This is also a problem when trying to print with Shutterfly and PhotoAccess. I'm not sure if this is accounted for yet in the future versions. It would probably be an easy enough problem to solve with Shutterfly and PhotoAccess - just allow those URLs are referrers if the modules are activated. The slideshow might be a little more difficult, would probably need to use some type of encrypted handshake between the client and the server.
Posts: 8601
That is fixed in current cvs or nightly snapshots for slideshow applet. If you want to print from shutterfly/photoaccess you need to add those domains to the allowed list in URL Rewrite site admin, Setup tab.
Posts: 181
Hmmm. I hav gallery 1.5.1, and I see this problem in one user account in the system but not on a different one! It's bizarre, though, because the allegedly failed download .jpg shows up in
~/.java/deployment/cache/javapi/v1.0/file/ and looks basically fine. I don't think my issue is the "hotlinking", because I haven't blocked that at all -- you can go directly to the images at all. And, if that were the problem, I don't think it'd work in the other user's account.
I've deleted ~/.java and all of ~/.mozilla, to no effect.
(I'm on Linux, by the way.)
Posts: 181
I enabled the java console, and the last message is:
basic: Loading http://photos.mkmiller.org/img/guen-10thmonth/PA227996.sized.jpg from cache
(Or, if the image isn't in cache already, a slightly different message about how it's put it in the cache.)
Posts: 181
Oh, duh, I've got it: the applet isn't respecting $TMPDIR, *and* is creating non-unique filenames in /tmp, and so they end up getting owned by the wrong user. This is actually a security flaw....
Posts: 181
See here:
http://gallery.menalto.com/node/40485