XnView Software

Hello,
Is it possible to have multiple copies of XnviewMp on a local network share the same categories.db file?


many thanks!

yes, read only?

Hello

Same question - with network access on Linux i unse .db file on network (only this file, .ini files are located in user directory) but as every computer access to this file with its own path (/home/USER/.gvfs/NETWORK DRIVE) as i add categories with one computer i can see categorized elements from another computer BUT file link is bad (because absolute path is not the same).

Would it be possible either to browse into xnview with a relative path (i.e. using $HOME variable, or ~/ ) or to share .db file with another system ? Using relative path ?

Export and import categories with XMP doesn't seem to work, maybe for the same reasons.

Thanks for help

maksou wrote: Would it be possible either to browse into xnview with a relative path (i.e. using $HOME variable, or ~/ ) or to share .db file with another system ? Using relative path ?

Do you have tried the base pathname?

maksou wrote:Hello

Same question - with network access on Linux i unse .db file on network (only this file, .ini files are located in user directory) but as every computer access to this file with its own path (/home/USER/.gvfs/NETWORK DRIVE) as i add categories with one computer i can see categorized elements from another computer BUT file link is bad (because absolute path is not the same).

Would it be possible either to browse into xnview with a relative path (i.e. using $HOME variable, or ~/ ) or to share .db file with another system ? Using relative path ?

Export and import categories with XMP doesn't seem to work, maybe for the same reasons.

Thanks for help

Usually this situation is handled by logging locally on your computer through the LAN/Server interface. IOW, in Windows therms, don't catalog the photos from F:\Photos\foo but make a share from F:\Photos (let's call it "SharedPhotos") and if your PC is called MyComputer then point your XnView to \\MyComputer\SharedPhotos and start working with this path (which is the same for all the workstations on your LAN, including the local host) and do not work directly with the local path (F:\Photos in our example)

HTH

xnview wrote:Do you have tried the base pathname?

I'm sorry, what do you mean ?

m.Th. wrote:Usually this situation is handled by logging locally on your computer through the LAN/Server interface. IOW, in Windows therms, don't catalog the photos from F:\Photos\foo but make a share from F:\Photos (let's call it "SharedPhotos") and if your PC is called MyComputer then point your XnView to \\MyComputer\SharedPhotos and start working with this path (which is the same for all the workstations on your LAN, including the local host) and do not work directly with the local path (F:\Photos in our example)

I understand - so it should work if i browse in XNVIEW using \\server-name\share-directory\foo ? i will try tomorrow

maksou wrote:

m.Th. wrote:Usually this situation is handled by logging locally on your computer through the LAN/Server interface. IOW, in Windows therms, don't catalog the photos from F:\Photos\foo but make a share from F:\Photos (let's call it "SharedPhotos") and if your PC is called MyComputer then point your XnView to \\MyComputer\SharedPhotos and start working with this path (which is the same for all the workstations on your LAN, including the local host) and do not work directly with the local path (F:\Photos in our example)

I understand - so it should work if i browse in XNVIEW using \\server-name\share-directory\foo ? i will try tomorrow

Please share you findings, but yes, it should work. XnView uses the OS API which is transparent regardless LAN/local filesystem. If it doesn't, then the failure is rather linked to some internal processing in the program in which Pierre assumes that the paths are local (starting with a drive letter etc.).

OTOH, SQLite (XnView's the database backend) is single user - the engine locks the entire file so there is NO possibility of concurent Read/Write on database. However, you can Read from the db. IOW, the first one who opens the db has read/write access the others read-only. If this scenario suits for you (and in enough cases it should) then go ahead. A full multi-user transactional db backend means to change the SQLite to something else, most probably to Firebird. But this is another story.

my0.02c++ & HTH

maksou wrote:OTOH, SQLite (XnView's the database backend) is single user - the engine locks the entire file so there is NO possibility of concurent Read/Write on database. However, you can Read from the db. IOW, the first one who opens the db has read/write access the others read-only. If this scenario suits for you (and in enough cases it should) then go ahead. A full multi-user transactional db backend means to change the SQLite to something else, most probably to Firebird. But this is another story.

ok so is there another way to use XNVIEW MP on network with simultaneous users ?

if there is no way, is it possible to get a flag or an alert for user when the DB is read-only at XNVIEW startup ? OR to startup XN VIEW in read-only if i want ?

maksou wrote:

m.Th. wrote:OTOH, SQLite (XnView's the database backend) is single user - the engine locks the entire file so there is NO possibility of concurent Read/Write on database. However, you can Read from the db. IOW, the first one who opens the db has read/write access the others read-only. If this scenario suits for you (and in enough cases it should) then go ahead. A full multi-user transactional db backend means to change the SQLite to something else, most probably to Firebird. But this is another story.

ok so is there another way to use XNVIEW MP on network with simultaneous users ?

Well, yes, if you're disciplined.

You can do it through XMP files, if XnViewMP supports XMP read/write operations for categories/rating/colours aso. I think that it does, but I didn't check it myself - I would be interested to know which is the status of XMP engine in this regard for all files (including RAW). In fact, this is a quite powerfull feature allowing us to have an open standard to communicate with other image managers and avoiding to be locked in in some program. If it is implemented correctly, it would attract many pros to XnView. Basically, each photo has a secondary file (called 'sidecar') with the same name and the extension .xmp in which all these catalog informations - and in some cases edits (see Lightroom, AfterShotPro etc.) - are stored in a (more or less) human readable form. Hence, if you set up XnViewMP to push/pull the catalog info to/from XMP files (usually the other programms allow you to do batch sync with XMP sidecars) then you have a bare-bone multiuser system through these XMP files. Just to be careful not to have two or more users cataloging simultaneously the same image because then only the last one will have his changes commited. Usually, when working through XMP (but not only) different users catalog different folders and hence the risk of collisions is mitigated. But XnViewMP needs to support XMP batch sync and sense. "XMP sensing" means that the program will check that the info from the catalog is older/different compared with the info from XMP files (usually there is a field in db which holds the datetime stamp) and shows a small icon/flag on the image thumbnail noticing the user that the info has changed. Then the update is usually like this: Select All -> Right Click Menu (or in the Main Menu) -> Update XMP to Catalog.

If it were to use a true ACID SQL server like Firebird (which can work both as embeddable database and as a full fledged Client/Server architecture, and it doesn't require administration - in fact the only viable alternative for SQLite now) all these things would be much more streamlined.

if there is no way, is it possible to get a flag or an alert for user when the DB is read-only at XNVIEW startup ? OR to startup XN VIEW in read-only if i want ?

My answer as user: dunno, I didn't check the program if it throws a warning.
My answer as programmer: certainly possible. It is easy for Pierre to check and/or to set/make certain things read-only.