Store Thumbnails database in photos folder
Moderators: XnTriq, helmut, xnview
Store Thumbnails database in photos folder
I have network of computers and server with photoarchive. I'd like to be able to use server thumbnails database on all computers, instead of importing or updating it.
IMHO best solution would be to store database of folder right in the folder itself, like "windows picture and fax viewer" does.
Please add apropriate option to F12->Browser->Thumbnails->Cache->Use Folder
IMHO best solution would be to store database of folder right in the folder itself, like "windows picture and fax viewer" does.
Please add apropriate option to F12->Browser->Thumbnails->Cache->Use Folder
Last edited by aibolit on Thu Mar 13, 2008 12:45 pm, edited 1 time in total.
Re: Store Thumbnails database in photos folder
+1 good idea, but as an option only.aibolit wrote:...
IMHO best solution would be to store database of folder right in the folder itself, like "windows picture and fax viewer" does - please add apropriate option to F12->Browser->Thumbnails->Cache->Use Folder
XnViewMP Linux X64 - Debian - X64
Yes JohnFredC, but here it is not exactly the probleme !
The benefit to have the thumbnails cache ( a xnview.db) directly in each folders is also to do not have to refresh all the tumbnails caches if you restructure your disque or change the name of yours directories, this is very usefull in this case to manage the tumbnails caches.
(same case for category.db, the link is lost if you rename your directories)
see here too:
http://newsgroup.xnview.com/viewtopic.php?t=14613
The benefit to have the thumbnails cache ( a xnview.db) directly in each folders is also to do not have to refresh all the tumbnails caches if you restructure your disque or change the name of yours directories, this is very usefull in this case to manage the tumbnails caches.
(same case for category.db, the link is lost if you rename your directories)
see here too:
http://newsgroup.xnview.com/viewtopic.php?t=14613
XnViewMP Linux X64 - Debian - X64
2 oops66
Actually I also would choose a schema where the thumbs are stored locally to the image! I'm also willing to take the performance "hit" that would necessarily occur for some XnView functions.
But I would prefer if there was some way for XnView to use both methods simultaneously and employ a background task to keep the "distributed" stores in synchronization with the "central" store.
Actually I also would choose a schema where the thumbs are stored locally to the image! I'm also willing to take the performance "hit" that would necessarily occur for some XnView functions.
But I would prefer if there was some way for XnView to use both methods simultaneously and employ a background task to keep the "distributed" stores in synchronization with the "central" store.
John
We have spend a lot of time on the XnView GUI design in this forum. Because of that XnView has extremely good usability and looks great!
But...
This concern (db centralized or not) and the possibility of multiple simultaneous users of the db (see this recent thread) are now, IMHO, more critical issues than the GUI.
With the advent of XnViewMP, and before too much programming effort has been expended by Pierre on it, there is an opportunity to design a new XnView data infrastructure that addresses all of these issues, and input/opinions from everyone should start now!
Does any one else agree?
But...
This concern (db centralized or not) and the possibility of multiple simultaneous users of the db (see this recent thread) are now, IMHO, more critical issues than the GUI.
With the advent of XnViewMP, and before too much programming effort has been expended by Pierre on it, there is an opportunity to design a new XnView data infrastructure that addresses all of these issues, and input/opinions from everyone should start now!
Does any one else agree?
John
In next version of XnViewMP, i use a better DB structure, more extensibleJohnFredC wrote: With the advent of XnViewMP, and before too much programming effort has been expended by Pierre on it, there is an opportunity to design a new XnView data infrastructure that addresses all of these issues, and input/opinions from everyone should start now!
Pierre.
Great!In next version of XnViewMP, i use a better DB structure, more extensible
One approach to the issue discussed in this thread would be to add a couple of new fields to the Folders table in the db...
Redirect: Integer
Whether to store a folder's data in the central db (Redirect=0) or in a db local to the folder (Redirect = 1) or in both places simultaneously (Redirect=2).
RedirectFilename: Text
The name of the "local" db in the folder. This field would only have a value for Redirect = 1 and Redirect = 2
John
I agree with this concept: centralized DB or not or both.JohnFredC wrote:...In next version of XnViewMP, i use a better DB structure, more extensible
Redirect: Integer
Whether to store a folder's data in the central db (Redirect=0) or in a db local to the folder (Redirect = 1) or in both places simultaneously (Redirect=2)....
Do not forget also, into MP version, a new field in the .db to store also the "IPTC keywords",... - Like in Digicam, to simplify and boost the search function:
http://newsgroup.xnview.com/viewtopic.p ... ht=digicam
http://newsgroup.xnview.com/viewtopic.p ... ht=digicam
XnViewMP Linux X64 - Debian - X64
I've had some time to think about this...
There needs to be a Synchronization field in the folder data record:
Synchronize: Integer
0=Don't synchronize | Redirect = 0
1=Local database (in folder) has authority/priority
2=Central database has authority/priority
3=Ask user what to do
There is much more to it, of course, than just fields in a table.
There needs to be a Synchronization field in the folder data record:
Synchronize: Integer
0=Don't synchronize | Redirect = 0
1=Local database (in folder) has authority/priority
2=Central database has authority/priority
3=Ask user what to do
There is much more to it, of course, than just fields in a table.
John