Thumbnails do not match ?

[m.Th.]

The database cannot be corrupted because of "multi-user environment". SQLite (XnView's DB engine) locks the DB at the first connect. All the other users which will try to connect will connect read-only.


Some questions:

The workstations are Windows workstations, right?

Do you have photos stored locally on different Workstations or all the photos are in a single place?

[edefault]

I guess the answer lies hidden in "multi-user" issues, and the data base, though initiated correctly, was prone to corruption from the very beginning.
I can't for sure rule out that, after a fresh installation of XnViewMP, it was first invoked from a console where superuser rights were already granted.
That would explain that a) the data base seemingly refused to be corrected later and b) images from a restricted area showed up as thumbnails.

The erroneous behaviour - thumbnail mismatch - showed up only after more images had been added to the file system later.

All data is on a single file server here ... , to which about two dozen users connect regularly, only one of them using XnViewMP.
I guess that shouldn't matter if remote file systems are mounted through NFS permanently, which makes the file System look like a single big disk.
Workstations are "mixed environment", Intel/AMD running Ubuntu 12.10, PowerPC Mini Macs running MacOS X and SGI Fuels running IRIX 6.5.28.

[Akovia]

Not sure this is the right place, but I'm experiencing something similar.

0.64
Xubuntu 12.0.4.4 64
Single user environment

Quite often when I start xnview I find thumbnails for images I haven't used in months show up for just some of my existing images. The difference from the OP is that a rebuilding of the thumbs does fix the problem, but it still keeps happening. Even in the same directories I've rebuilt the thumbs for.

[m.Th.]

Not sure this is the right place, but I'm experiencing something similar.

0.64
Xubuntu 12.0.4.4 64
Single user environment

Quite often when I start xnview I find thumbnails for images I haven't used in months show up for just some of my existing images. The difference from the OP is that a rebuilding of the thumbs does fix the problem, but it still keeps happening. Even in the same directories I've rebuilt the thumbs for.

Try this: Find all thumbs.db databases which you have. Delete/hide (rename etc.) all. It still happens?

[Akovia]

Try this: Find all thumbs.db databases which you have. Delete/hide (rename etc.) all. It still happens?

I'd imagine that that would work as everything used to work fine. Just thought I'd bring it up so maybe it could be troubleshot to find the root of the problem instead of deleting the DB every time it happens.

I have a huge library with a ton of folders, and looking at the DB settings now I realize I have "Memory usage for database engine" set at 300 MiB, but below it states..
Cache Maintenance [cache size 7.50 MiB - 494.49 MiB]

Not sure what the range means, but if my db is larger than the amount set for memory usage, could that be the problem?

[m.Th.]

Just thought I'd bring it up so maybe it could be troubleshot to find the root of the problem...

In the single-user environment the most probable case (AFAIS now) is a mismatch between xnview.db (where the file names are stored) and thumbs.db.

For example:

1/1/2014: We start to work and we index 5000 photos. The FileID and ThumbID unique numbers (Primary Keys - PKs in the language of DBAs) are from 1 to 5000.
10/1/2014: Something "magic" happens (we change the folder of databases, backup etc.) and XnView MP looks to another DB folder - hence it generates automatically an empty xnview.db and thumbs.db
20/1/2014: We work and in the new databases are gathered files from 1 to 200.
30/1/2014: Something "magic" happens (copy, synchronization, backup restore etc.) and the thumbs.db from 1/1/2014 reaches in the folder created in 10/1

In this situation the FileID no. 123 from the Xnview.db created at 10/1/2014 points to the ThumbID no. 123 from the thumbs.db created in 1/1/2014. Of course the thumbs does not match. A classical situation of referential integrity breakage.

...but of course can be some very odd bug in the program - thing which I doubt because all the data is ok (usually in these situations data corruption appears with a ton of crashes and other malfunctions).

I have a huge library with a ton of folders, and looking at the DB settings now I realize I have "Memory usage for database engine" set at 300 MiB, but below it states..
Cache Maintenance [cache size 7.50 MiB - 494.49 MiB]

Not sure what the range means, but if my db is larger than the amount set for memory usage, could that be the problem?

No isn't a problem per se. It just means that the program will not load the entire db in memory (ok, if it says 494 you should allow more because there are other structures involved - indexes etc.). In fact in day-by-day world of database servers a least of part of DB is on disk.

In fact isn't a problem at all, because you will not look at all folders in a single session, so the DB engine will not be forced to bring all data in memory.

[Akovia]

Thanks for the detailed reply.
There have indeed been quite a few program crashes, so that makes sense that it could have caused the corruption.

Just didn't want to delete all of my thumb DBs yet in case you wanted me to check something to help track down the problem. I'll just delete them all and start over.

Thanks again.

[edefault]

After an upgrade to Ubuntu 12.04LTS, the same thing happened again, program crash included ... some "referential integrity breakage".
Deletion of thumbnail database and program restart, re-reading all images did the trick. I wonder: is it possible to detect this beforehand?