24 Messages
•
4.4K Points
Sun, May 1, 2011 9:55 PM
411
Lightroom Classic and CC: Allow Catalog to be stored on a networked drive.
I'd love to make LR more multi-computer friendly. I have no doubt that there's probably database architecture issues and a host of other barriers... But I have to believe that the need for either multi-user or at at lease multi-computer use is widely desired. And yes, I know you can do the catalog import export thing but I find this less than ideal.
Ideas
•
Updated
6 months ago
335
202
411
Helpful Widget
How can we improve?
Tags
multi-user
catalog
sharing
network
Responses
tonyr_2628057
1 Message
•
82 Points
9 years ago
0
rodney_l_wright
14 Messages
•
570 Points
9 years ago
I am a (volunteer) database administrator at the National Air and Space Museum (NASM) and am coordinator for a major internal database using Microsoft Access. For years, MS Access has had no problem with record level locking and multiuser access. We are converting this database to MySQL and so far have had very good success. Multiuser access in MySQL works well.
If SQLite is the problem, I suggest Adobe seriously evaluate recasting Lightroom to use MySQL.
My personal reason for needing multi-user access is that I maintain a personal database of over 40,000 photos and this is growing very quickly as I add both family and air & space photos (I am also a docent at NASM and share responsibility for training new docents, so a photo database is important in that regard too.)
At home I have Microsoft Home Server and a small 3-client machine network (my machine, my wife's machine, and my laptop.) Currently, we have the Lightroom catalog installed on an USB connected external drive and move it from machine to machine whenever one of us needs to access Lightroom (and that is frequent.) Both my wife and I need concurrent shared access to the same Lightroom database. Record-level locking would prevent use both from working on the same photo at the same time. Being able to install the catalog on the server would greatly simplify life for us (and would help to ensure domestic tranquility by preventing conflicts over whose work is more important or highest priority.)
At NASM, we have an intranet implemented using MS server with Windows clients. We don't currently have Lightroom installed on our machines because it is a single-user application. I certainly would recommend it in a heartbeat if there was a true multiuser version available.
In regard to licensing, I think Adobe should consider a "family license" much like Micorosoft, Norton, McAffee, etc. This would authorize up to say, three concurrent uses of Lightroom using a single license.
Lightroom should also be authorized for organizations by selling licenses for multi-user versions. We certainly would be interested in that for our Education Department.
Please be advised that NASM has NOT authorized me to speak for them or to commit. Since I am a volunteer, any such interpretation of my comments would cause grief to me and to NASM. I appreciate your consideration in considering these suggestions.
2
dantull
Employee
•
166 Messages
•
3K Points
9 years ago
Note that even a multi-user MySQL installation doesn't just put a file on a network share and let file locking manage concurrent access. It has a network daemon and clients connect on a TCP port to make queries and get data.
So SQLite isn't the reason we don't have a multi-user system, it's the reason we don't do multi-user by just putting the catalog files on a network share.
Besides, multi-user Lightroom isn't just about the catalog data. There's previews, the original image files (neither of these are in the lrcat file), and lots of other pieces that would have to be managed as well.
If the task of making Lightroom a multi-user, multi-machine system is a book, the SQLite versus MySQL part is a footnote. Ok, maybe a short chapter. :)
0
louis_sherwin
149 Messages
•
3.3K Points
9 years ago
It occurs to me that this topic probably could be split in two separate but related discussions.
1. Multi-user - Two or more people working on a shared catalog and image database. This requires a client-server architecture with the necessary file locking etc. This is not the common use model but would be highly desired by anyone with a small studio and one or more assistances up to an organization managing a large archive.
2. Multi-computer - One person working with one or more catalogs. I think that today this covers a large majority of Lightroom users. Many of us regularly use a lap top computer in the field to start working on the days images and then want to have a say to simply merge this back into or main catalog on the desktop at home.
In either case you should probably treat the previews more like cache than "data". They are being regenerated all the time anyway as you make edits so it make sense to me that my previews would always be localized to my local computer user workspace.
-louie
6
bobmeyer
4 Messages
•
214 Points
9 years ago
0
rodney_l_wright
14 Messages
•
570 Points
9 years ago
0
0
rodney_l_wright
14 Messages
•
570 Points
9 years ago
0
0
JeffreyTranberry
Adobe Administrator
•
15.8K Messages
•
295K Points
9 years ago
Sr. Product Manager, Adobe Digital Imaging
11
0
walker_blackwell
7 Messages
•
230 Points
9 years ago
I run networked LR catalogues this way by putting them inside writable DMG files hosted on a fiber server 5 miles away from my desk. It works like a charm and haven't had a corruption once since I started 3 years ago. (only one client at a time mind you.)
This mutli-user thing is totally normal workflow and there is no reason why a networked DB would cause any performance slowdowns or be a trouble to build. Local cache/ripping would have to certainly be implemented but how much time does it take to upload a 3 megabyte jpg to a central cache file? Less than 1/2 of a second at gigabit. I could see a multi-client interface actually increasing the speed of Lightroom in the future by farming out intensive tasks to multiple idle computers just like Final Cut does today.
As long as the server is running memcached and is powerful enough, I don't see this back and forth of part of the db being a problem at all really. SQlite can run multi-user as long as their is a layer between it and the client. So build a layer that presents Lightroom clients with their "individual" sqlite db. That individual sqlite db is really constantly updated by all the other users and the only sql that is unique (and that the client caches in memory) is each client's opened files. Networks are fast enough.
Walker
0
0
richmeade
8 Messages
•
176 Points
9 years ago
Seems like an obvious next step, so places like my studio can run multiple machines and reference the same catalog...
This reply was created from a merged topic originally titled
Network Catalog.
0
0
lynn_bayer
6 Messages
•
178 Points
9 years ago
We have the usb harddrive solution but it more a workaround.
0
0
phil_pool
18 Messages
•
232 Points
9 years ago
From a business standpoint, most 'studios/photographers' work by themselves or with staff of three or smaller. Most of us smaller operators would be thrilled to be able to leave our catalog and images on a 'server' and then access from our laptops and maybe one or two desktops in our work area.
Having the mega stock photo business with large databases and then everyone else would seem that having two different versions of LR would be your answer.
Is this unreasonable? I don't know.
0
0
thomas_achermann
8 Messages
•
246 Points
9 years ago
1. Catalog Sync: for single-user/multi-computer use. A automatized sync of a catalog between lets say a laptop and a studio computer. That would satisfy a lot of users
2. Networked Catalog: I'm not sure if this is doable (avoiding db corruption) but I would imagine that the performance of such a catalog would be 'less then desirable' even over Gb-network
3. Lightroom Server: a real client/server application for larger working environments. But this would then require a dedicated SQL server AND file-server (to store the RAW images and previews) and a new client application. But I would expect a hefty price tag on such a version
I'm sure there are people at Adobe that have already looked into this - but I'm also sure it is not easy to come up with a real good solution, especially because the possible scenarios are going in very different directions.
0
0
phil_pool
18 Messages
•
232 Points
9 years ago
0
0
mark_bortz
8 Messages
•
150 Points
9 years ago
2
0