"Fix your Gallery" Caused Total Corruption

Cygon
Cygon's picture

Joined: 2005-10-16
Posts: 19
Posted: Sat, 2013-05-11 21:44

I've had my gallery installation running since the first G3 release and over time added about 70,000 photos to it.

Recently, because gallery only displayed pictures in small and smaller size (either resized to fit the theme or limited by browser window), I set the "resized image size" to 16,384 so that I could at least have full size images.

I resumed the resize every now and then until, after a period of about 3 months, it was finished. Everything was fine, except that it reported that 20 thumbnails had to be rebuild and did nothing if I attempted to do so. So I clicked on "Fix your Gallery."

Well, it went berserk on my database, it seems. All folders lost their thumbnails, entries displayed insane folder paths (eg. things like folder X is displayed as having the path \A\B\C\D\E, but if I click on D, folder D is displayed as being in \A\D).

Repeating the "Fix your Gallery" task brought the thumbnails back but left the misplaced paths. In some cases, the URL is http://localhost/a/d but the folder displays as \A\B\C\D in the breadcrumbs.

I've already accepted that I'll have to start over and I'll loose all my tags and descriptions and names. Though if anyone has some recommendations on how to find the cause of the corruption, I've got nothing to loose and am willing to try ;-)

 
inposure
inposure's picture

Joined: 2010-04-23
Posts: 304
Posted: Sat, 2013-05-11 22:11

Has happened to me too. I do not touch the maintenance section after that, and frankly the entire Gallery idea is dead until that bug is tracked down and fixed really good.

http://galleryproject.org/gallery_3.0.4_feedback

 
Cygon
Cygon's picture

Joined: 2005-10-16
Posts: 19
Posted: Sun, 2013-05-12 08:05

The gallery version this happened with was 3.0.4 running on a 64-bit Gentoo Linux system w/PHP 5.4. I just upgraded to gallery 3.0.7 and repeated the "Fix you Gallery" step - now the ORM is unhappy.

2013-05-12 09:57:16 +02:00 --- error: exception 'ORM_Validation_Exception' with message 'ORM Validation has failed for items model' in /var/www/localhost/htdocs/gallery/system/libraries/ORM_Validation_Exception.php:20
Stack trace:
#0 /var/www/localhost/htdocs/gallery/system/libraries/ORM.php(755): ORM_Validation_Exception_Core::handle_validation('items', Object(Validation))
#1 /var/www/localhost/htdocs/gallery/modules/gallery/models/item.php(887): ORM_Core->validate(NULL)
#2 /var/www/localhost/htdocs/gallery/system/libraries/ORM.php(778): Item_Model_Core->validate()
#3 /var/www/localhost/htdocs/gallery/modules/gallery/libraries/MY_ORM.php(34): ORM_Core->save()
#4 /var/www/localhost/htdocs/gallery/modules/gallery/libraries/ORM_MPTT.php(79): ORM->save()
#5 /var/www/localhost/htdocs/gallery/modules/gallery/models/item.php(533): ORM_MPTT_Core->save()
#6 /var/www/localhost/htdocs/gallery/modules/gallery/models/item.php(305): Item_Model_Core->save()

I wish it told me which item violated its model in what way. I'll see if I can find out more by either enabling gallery debugging or resorting to echo statements.

 
Cygon
Cygon's picture

Joined: 2005-10-16
Posts: 19
Posted: Sun, 2013-05-12 09:28

Hacked 'modules/gallery/helpers/graphics.php' to display the item id and path when something fails during resize because the item name is just a page number in my case:

Kohana_Log::add("error", "Caught exception rebuilding images: {$item->title} ({$item->id}) ({$item->resize_path()})\n" .
$e->getMessage() . "\n" . $e->getTraceAsString());

After checking with phpMyAdmin, it turns out the path was of a single image in a folder that didn't exist (but may have existed at one time). Looks like data left behind after a move operation in the organizer.

The "ORM Validation has failed for items model" remains and I still have 19 thumbnails that aren't rebuilt (but no error message). With debugging enabled, the logs reveal this:

2013-05-12 11:13:47 +02:00 --- error: Validation errors: Array
(
[mime_type] => invalid
[name] => illegal_data_file_extension
)

 
shadlaws

Joined: 2012-03-14
Posts: 183
Posted: Sun, 2013-05-12 13:11

@cygon - don't worry, all hope is not lost :-). It sounds like the only parts of your database that are corrupted are the "left_ptr" and "right_ptr" columns of the "items" table. The issue is that the "Fix my gallery" task was started, but not finished, leaving them in a half-rewritten state.

The simplest solution to this is to start the task and wait until it's finished... which will take forever. I know. Good news: I recently revised this a bit for Gallery 3.1 to make it a ton faster, so that issue will soon disappear.

As for the 19 photos that are failing to rebuild, it sounds like they have invalid file extensions. Can you check and see what they are?

Take care,
Shad

 
Cygon
Cygon's picture

Joined: 2005-10-16
Posts: 19
Posted: Sun, 2013-05-12 17:29

The "Fix my Gallery" task does not take forever, it fails with "ORM Validation has failed for items model." :)

The log of the thumbnail rebuild task only outputs the image titles which in my case are page numbers, appearing thousands of times in my gallery. I hacked modules/gallery/helpers/gallery_task.php to display the item id:

$errors[] = t("Unable to rebuild images for '%title' (%id)",
array(
"title" => html::purify($item->title),
"id" => html::purify($item->id)
));

Which led me to some .swf files. However, my allowed_extensions is set to

a:10:{i:0;s:3:"avi";i:1;s:3:"mpg";i:2;s:4:"mpeg";i:3;s:3:"mov";i:4;s:3:"wmv";i:5;s:3:"asf";i:6;s:3:"mts";i:7;s:3:"swf";i:8;s:3:"mkv";i:9;s:3:"flv";}

 
shadlaws

Joined: 2012-03-14
Posts: 183
Posted: Mon, 2013-05-13 20:15

@cygon - Hmm, "allowed_extensions" sounds like you have the videos module installed, no? If so, that's likely part of the problem: that module is obsolete. Among other things, it uses it's own version of the core item model which does not extend but instead *replaces* Gallery's model... and it hasn't been updated since Gallery 3.0.1. For more details, see http://codex.galleryproject.org/Gallery3:User_guide:Obsolete_modules

Take care,
Shad

 
Cygon
Cygon's picture

Joined: 2005-10-16
Posts: 19
Posted: Tue, 2013-05-14 06:10

I had it installed when running Gallery 3.0.4 but removed it when I upgraded to Gallery 3.0.7, after checking the page you linked to. The corruption happened with Gallery 3.0.4 + videos, of course, so that combination might well be to blame.

After removing the videos module, I have edited allowed_extensions by hand to include certain file types. I understand that ffmpeg may not be able to create thumbnails for .swf files, thought of course it would be nice if I could tell Gallery to shut up about it. I'd love to store some .pdf and .xml files, too :)

In any case, I believe that the thumbnail rebuild problem isn't related to the ORM validation issue I'm observing. To be sure, I'll remove those files and see what happens.

 
shadlaws

Joined: 2012-03-14
Posts: 183
Posted: Tue, 2013-05-14 12:25

@cygon - a couple followups...

I just pushed the patch that makes "fix your gallery" a ton faster to the 3.0.x branch (http://sourceforge.net/apps/trac/gallery/ticket/2069), so hopefully this will go faster in the future :-).

Re: videos, good call on removing it. The only catch is that "allowed_extensions" was a videos parameter, so Gallery is ignoring your hand-edited changes. I'd recommend getting "movie_tools" which will give you more-or-less the same functionality. You can add as many types as you wish!

Re: PDFs, I'd recommend getting the "pdf" module which will not only allow them but also generate proper thumbnails and views for them.

Hope that helps!

Take care,
Shad

 
gavin1993

Joined: 2013-05-18
Posts: 1
Posted: Sat, 2013-05-18 08:00

I had this problem too, Thanks, shadlaws! Your information helped a lot! :)