My Albums reorder themselves

No one else has ever experienced this?

Man.... am I odd man out.

Yes, I've seen this error too.

I recently moved web hosts *and* upgraded to 1.5-RC2 as part of the move. I got my gallery up and running on the new web host and things were going smoothly for a day or two. One morning I visited the page and found all the albums re-ordered without any explanation. The sorting was a bit bizarre, but I think the albums may have been sorted by file date... Oldest albums first.

I did a little investigating and came to the conclusion that the albumdb.dat file was likely corrupted, and that's what caused the problem. Gallery automatically "fixed" the corrupt DB by re-sorting the albums and updating the DB file. You can recreate the problem if you manually corrupt the DB file and add two "album 1" entries. However, I'm still not sure how the file was corrupted in the first place.

I fixed the problem by restoring an old version of the albumdb.dat file (along with a little bit of manual editing). I haven't seen the problem since (2 weeks now). I've also been backing up the albumdb.dat file anytime I add new albums.

Finally, I enabled file locking in the config.php file as a precaution.

Actually, I figured it out.

For whatever reason, when upgrading previous albums, my temp folder was not emptying itself. I would still have garbage temp files in there.

I simply emptied the temp folder after upgrading everything and have been cruising along smoothly ever since....

We definitely try to give you the best product we can, but you must understand we're volunteers. We admit G1 has major design flaws, and we think we'll do better at addressing those with our new major version G2--you can even help us test it!

If you are not satisfied with our product, nobody is forcing you to use it. Also realize nobody is forcing us to help you.

I'm sorry that you feel that Gallery is junk. We do what we can in our spare time, and if that's not enough then you're free to pursue other alternatives and we wish you the best of luck.

If, on the other hand, you'd like to see us fix this problem then you might start by filing a bug with as much detail as you can muster about this and offering up constructive criticism. If you can think of any solutions, that would be a good place to suggest them.

My guess is that concurrent accesses to your albumdb.dat file are causing it to get corrupted. I'd look in your Apache error logs for any traces of crashed http servers. I'd also make regular backups of your albumdb.dat file so that you can roll back to that if necessary (good idea to back it up after you add new albums). And enable flock based locking where possible.

Also, consider moving forward to G2. One of the difficulties with G1 is that it's very difficult to manage concurrent file access without the possibility of corruption. G2 uses a database as a semaphore for concurrent access and as a result is much more reliable.

hi guys. I have the exact nightmare problem. I found a temporal (dirty hack) solution.

In /classes/AlbumDB.php

comment following lines (from #35 and next ones)

if (strcmp($tmp, "")) {
$this->albumOrder = unserialize($tmp);

// albumdb.dat is corrupt, rebuild it
//if (empty($this->albumOrder)) {
//$this->albumOrder = array();
//}
//$changed = 1;

Greets!
Wieland Kublun
www.alohagdl.com Webmaster
www.kublun.com // personal website

I have the same problem as well. I have just a few top level albums (all containing multiple sub albums). I've noticed a few times now where i'll pull up my gallery site in a browser and the top level albums have mysteriously reordered themselves.

:: Running Gallery v1.5

- Lee

My apologies for not replying to this thread earlier, I don't seem to get email notifications from here very often (if at all)

I understand this and I apologies for the rude nature of the post, it was unwarranted. I have been using gallery for many years and it is only recently that I have started to have problems with it.

If you think there is value in this then I'll certainly raise a bug report. I do of course keep backups but it's difficult to know where and when problem occur. When albumdb.dat gets corrupted the symptoms vary from albums being listed in entirely the wrong order to albums not appearing at the *top* of the album list.

Backup up after new album creatioon isn't really as easy as that as I have over 500 albums and many contributors.

Will try that now

Nobody is forcing me to use gallery but I'm in a position where I have 15,000 images collected over the last years and now option of getting them out of gallery format into another gallery container, I have looked at the possibility of importing my gallery into something else without much luck

This problem is happening to me every couple of days now, my gallery is pretty much unusable at the moment. Every time this happens I have to restore from backups then move each album that has been created since to the top of the tree.

Is there any way to reorder the albums by creation date? AFAIKS this information isn't captured anywhere - is it?

WRT to apache errors the only ones I get are php maximum execution times - mine is set to 30 seconds and this:

I am trialling g2 at the moment but integration seems to be a nightmare.

I suspect that issue is tricky to fix because of the limitation of the flat file database which holds the album data. Personally I think there needs to be a simple backup of albumsdb.dat everytime there is an operation on it.

I'm also confused by the suggestion that this is a locking issue as I'm pretty sure that the problem doesn't occur with concurrrent writes and if it was a locking issue I think the whole file would be truncated to a zero length file.

In fact looking at the code, flock() is indeed used to protect files getting opened and written to:

function safe_serialize($obj, $file) {
        global $gallery;

        if (!strcmp($gallery->app->use_flock, "yes")) {
                /* Acquire an advisory lock */
                $lockfd = fs_fopen("$file.lock", "a+");
                if (!$lockfd) {
                        echo gallery_error(sprintf(_("Could not open lock file (%s)!"),
                                                "$file.lock"));
                        return 0;
                }
                if (!flock($lockfd, LOCK_EX)) {
                        echo gallery_error(sprintf(_("Could not acquire lock (%s)!"),
                                                "$file.lock"));
                        return 0;
                }
        }

My gallery has just done this again and I have ended up with albums from 2000 at the top.

I'm left with the choice of either spending serious amounts of time fixing this every day or so or using G2 which, to be frank, doesn't look finished to me.

Gutted.

Again today

I have and personally I don't think it's mature enough to move all 15,000 pictures to it yet

yea i tried it deleted all temp file, but no same issue, question though why are the temp files not being deleted auto when the script is done with it ?

G2 is far, far more mature in respect to having as many images as you do. There is one commercial sites based on ALPHA versions of G2 that have more than 500,000 images and something like 50,000 users. I believe its "care2", though my figures could be a little off (higher now, i'd imagine). It scales very very well.

You can customize G2 far more than you can G1, and its light years easier. There is a "classic" theme that includes the sub-album list like G1 can have. If you remove all the side-bar items, it will look even better. In the long term, you will almost certainly be happier and better served by G2. I would not recommend REMOVING your G1, but G2 will happily install alongside G1 and import data from it (not removing it from G1!) so you can test it out.

In linux, the /tmp dir is made to be entirely disposable. Its possible that if you nuke something WHILE its in use, some poor sap will have a minor issue or two, but thats about it. If you configured your own special /tmp dir for gallery (in your html doc root maybe?) then you won't be doing any damage unless someone happens to be uploading an image RIGHT at that moment. Some linux distributions actually clear the /tmp dir at every boot... though with linux, who knows if it would happen more than once a year

For those of you who've been experiencing this problem, you might try what I've done and restrict search engines from crawling the rss.php file. I had been experiencing this problem nightly, but after doing what I outlined in this thread, I haven't had the problem since. It seems that rapidly crawling the RSS feed was somehow causing the albumdb.dat file to be corrupted.

Other people are reporting that excluding their Gallery RSS feed from being crawled resolves this issue for them. I'd encourage any of you still experiencing this problem to try this work-around. (It's only a work-around, since it'd be preferable to have my RSS feeds available to search engines.)

Well i checked my error logs and i was missing the robots.txt file...somehow.

I used a robots.txt generator and set it to deny all and it's been ok for a day now :D

UPDATE : Still working like a charm...i guess setting the deny all in the txt file workz :D

~Mike

repeatedly happening to me. gonna try the rss.php thing (i am just going to delete it)

Carl

I have been struggling with this problem for months, it only seems to affect the top-level albums though. We have 11K photos with 10 top-level albums, not much uploading going on right now, simultaneous uploading would be very rare.

I tried creating a robot.txt file to deny access to rss.php but after a week the problem was still happening, so I have temporarily disabled my rss feed. Album order has been stable for 1 week, but this is a terrible workaround!

Where can we recommend that this bug be checked out for potential fixing in future 1.x versions, if it is not already?

(Running 1.5-pl1 on Solaris.)

well..i could not fix it either..

There has to be a fix for this, anyone? Been able to solve the problem?

Haven't gotten a response to this, so bumping up.

Damn damn damn! For some reason, I thought this has been taken care on in the 1.52 builds, so a couple of weeks ago, I went and took an evening re-sorting my albums back to the correct order, and everything was fine. This morning? Back in random order! I think I might remove the bit of "safety code" than Jens mentions further up the thread, and see how things go.

My gallery has just done this as well v1.5.1 - you all talk about re-ordering your albums? How do you do this? I can't find the option to reorder my albums anywhere? Would really appreciate your help - thanks Josh