Thumbnails do not match ?

[edefault]

I didn't manage to find an issue like mine here, so: What am I missing if I get a complete mismatch of thumbnails?

I tried to re-read directories, fiddled with setup... a forced rebuild of the thumbnail database does not come to an end, or, to be more precise, not within two days. Since there's some server's huge network storage mounted here - is it supposed to take that long?
Does multiple access to a server's image library from different workplaces mangle the data base eventually, or are there different variants of the data base somehow, some outdated?

TIA

[m.Th.]

What do you mean by "complete mismatch of thumbnails"?

Do you mean that a file with the name foo.jpg is shown in Windows' viewer with one image and in XnView's thumbnail with another one?

Then try View | Rebuild Thumbnails on that folder. Does it help?

[edefault]

Do you mean that a file with the name foo.jpg is shown in Windows' viewer with one image and in XnView's thumbnail with another one?

Exactly! To be more precise again:
My post is about XnViewMP 0.61, and it is Ubuntu or MacOS X I'm running it on here, _not_ Windows. I didn't try the MacOS variant lately, though.
Thats's the viewer frontends, the images are on server drives running Ubuntu.

Y'know, the browser in XnViewMP (as in XnView) eases the search for a specific image when one forgot the file name, date or location.
But my thumbnals in the browser do not match the images any more. Whatever is selected, surprise, surprise: something entirely different shows up :-O
Have a look:

Edit: The image of a cannondale electric bike shows up as a couple driving a bike with a sidecar in thumbnails - no match.

[xnview]

Do you have the problem only with search??

[edefault]

Hope I got that right ... by "search" you mean the image browser view, right?
I thought that is what thumbnails are meant for... or what else?
Viewed in "Layout 1" it looks like this:

A house made mainly of garages - while the thumbnail shows a car on the sidewalk.
No match.

[m.Th.]

Thanks for the feedback, really appreciated but...

I meant the following:

1. Go to menu View
2. Click on Rebuild Thumbnails

Does it fix the problem?

[xnview]

Really, could you try with a clean database?

[edefault]

Thanks for the feedback, really appreciated but...

I meant the following:

1. Go to menu View
2. Click on Rebuild Thumbnails

Does it fix the problem?

Nope. That was of course the first thing I tried.
Now you suggested that I cleared the database es well /setup/database/clear all).
Still thumbnail mismatch ... am I supposed to close/restart XnViewMP?

[edefault]

... am I supposed to close/restart XnViewMP?

Obviously, yes. Exited XnViewMP, then tried to invoke it again. Dang!
It immediately crashed without notice. On a second attempt, everything is fine again.
I had the thumbnail cache disabled in the first place.

[xnview]

Please try to remove all .db (if you don't use categories), you have the path in About dialog

[edefault]

Please try to remove all .db

Now I did ... and enabled caching again. Yet everything is fine.
I wonder what possibly went wrong and will keep an eye on it.

[xnview]

Please try to remove all .db

Now I did ... and enabled caching again. Yet everything is fine.
I wonder what possibly went wrong and will keep an eye on it.

yes it's really strange...

[helmut]

Please try to remove all .db

Now I did ... and enabled caching again. Yet everything is fine.
I wonder what possibly went wrong and will keep an eye on it.

My guess is that this is a problem in a multi-user environment when the database is shared.

[m.Th.]

Please try to remove all .db

Now I did ... and enabled caching again. Yet everything is fine.
I wonder what possibly went wrong and will keep an eye on it.

My guess is that this is a problem in a multi-user environment when the database is shared.

Hmmm... to have a conflict here we need to have the same name and the same path. But this is possible when both user A and B have on their local workstations photos straight from the camera which have a cycling counter.

Hence, if Workstation A has in C:\DCIM\100CANON\ the files IMG_0001.JPG ...IMG_0888.JPG and Workstation B has in the same path same file names but with different content, then if the DB is on \\Server\Share\XnView.DB and is updated from Workstation A, the Workstation B will, indeed, see the wrong thumbnails.

This isn't a problem with XnView in itself but with network administration.

Some solutions:

1. Put the files in a central storage: \\File-Server\MyShare\ and catalog them there
2. Catalog files by using UNCs. So no more c:\DCIM\ but \\Workstation-A\PhotoShare\... - this requires a share on workstation, thing which can be problematic WRT security.
3. Use unique file names and/or folders. For ex. use date/time, some keywords related to the content of the folder, generate a hash based on the date-time or on something else etc.

4. A combination of above.

[edefault]

I also suspected that "a multi-user environment" affected the database somehow.
A tricky combination of different access rights, mingled program and/or file versions, outdated files ... same as ever.

In fact, the data - quite a lot of it - is located here on a single file server which runs a raid5 array of terabyte disks.
Among two dozen or so users there's only a single one (me) who runs XnViewMP, always through his own account,
but, of course, from different workplaces. Theoretically this shouldn't affect the thumbnail database.
But apparently it got corrupted, dunno how, yet.
Thought it would heal through rebuild of thumbnails.

When XnViewMP builds that database, it scans all available data for known image formats, right?
The erratic thumbnails I experienced included some from images which were located in areas within the file system,
where some subdirectories granted no access (belonged to different users ore were otherwise restricted).
That should not result in thumbnail mismatch? Wild guessing? Yes, unfortunately.

I'll keep an eye on it ... and continue wild guessing ...

It is quite probable that there are images with identical file names in different directories, since these come from cameras which use a standard naming scheme.
If that can confuse the database building process this is not easily solved.

Another thing: It is possible that former users or versions of XnView left remnants of former database building processes elsewhere.
What if there are outdated .xnview or .xnviewmp directories somewhere else? And contain such remnants of earlier databases?
Are these used, i. e. ist the database hierarchical somehow and tries to depend on that?