GNOME Bugzilla – Bug 432759
update of the thumbnail index when files are added
Last modified: 2007-06-14 11:55:23 UTC
When scanning images to the catalog shown in gthumb no automatic update is done when each image are created. Instead the user has to click up to the parent catalog and back to refresh the index. Other information: Nautilus does this. I think it is based on dbus events but I'm not sure, it could be polled also which is not so good.
Joakim, It is supposed to spot the new file automatically. If I copy a file into the current folder using "cp /otherfolder/test.jpg /currentfolder/" from a terminal, gThumb updates the thumbnails a few seconds later. Does that work correctly for you (i.e., command line copying + auto-refresh)? Maybe something odd is happening with the scanner software - perhaps a temporary file is created and renamed before gThumb properly deals with the original name of the temporary file. I'm just guessing, here... - I can't reproduce that effect with any shell commands (cp followed by mv, for example). Possibly related to: bug 98931 bug 425094 (is this fixed for you?) We need some more clues... - Mike
Joakim, Is your scanning software running on Linux, using the native filesystem? (As compared to running on MS Windows, and accessing the folder via Samba...) I managed to reproduce a problem similar to what you described... I was saving an image file being received via a RS-232 port on a Windows program, which was saving to the linux server folder while gThumb was also watching the folder. gThumb showed the mime-type icons instead of thumbnails. I think this is related to bug 98931... maybe it tries to thumbnail before the file is complete, and doesn't try again when the file really is complete. - Mike
Mike, I am using the Linux version "vuescan" and stores the output to the local filesystem. The scanner is connected through USB but that is probably unrelated. I have not managed to get the TRUNK to crash but have only scanned a few strips so it is still possible that the problem exists, I'll report here if it happens again. If I copy an image into the folder it appears as you say but not when I use vuescan to produce it there. I also tried to move it there and to create a hard link to there and all worked as you say. The only thing I can think of is that gthumb is too quick and that it doesn't retry. I can clearily see that Nautilus repeatedly retries to create the thumbnail until it suceeeds while vuescan creates the file. During this process a generic icon is shown. I will do an strace of a scan with vuescan to see what system calls it uses. BRB // Joakim
Created attachment 86951 [details] strace snippet from vuescan scan creating undetected file OK, so here is a part of the pretty extensive strace log I got from scanning one image. Maybe the use of mmap somehow evades the update trigger in gthumb. // Joakim
This should be fixed in trunk and metadata-ideas svn rev 1653 and later. Let me know if it works for you. - Mike
I can confirm that this is fixed in trunk now. When a picture is scanned it is now immediatelly visible in the thumbnail index. Thanks! Joakim
*** Bug 98931 has been marked as a duplicate of this bug. ***