• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
431

P: Allow Catalog to be stored on a networked drive.

Explorer ,
May 01, 2011 May 01, 2011

Copy link to clipboard

Copied

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.

Idea No status
TOPICS
macOS , Windows

Views

3.8K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
replies 565 Replies 565
565 Comments
LEGEND ,
May 23, 2011 May 23, 2011

Copy link to clipboard

Copied

Thanks, John, that's very useful information. It appears that one could stay out of trouble by making sure that there are no access conflicts. I understand that even commercial studios use the network "trick" without problems.

Votes

Translate

Translate

Report

Report
Community Expert ,
May 23, 2011 May 23, 2011

Copy link to clipboard

Copied

Dan Tull did do some tests and managed to repeatedly corrupt his catalogs beyond repair, just as a result of the network connection dropping at the wrong moment. That's not to say that they won't find a way round it, but there are legitimate reasons why it hasn't happened yet.
_______________________________________________
Victoria - The Lightroom Queen - Author of the Lightroom Missing FAQ & Edit on the Go books.

Votes

Translate

Translate

Report

Report
LEGEND ,
May 24, 2011 May 24, 2011

Copy link to clipboard

Copied

If I remember correctly, Dan Tull was experimenting with simultaneous accesses to see whether the sqlite locking problems would indeed be prohibitive, as referred to above by John Ellis, and since there were problems, it confirmed the hunch that a full-blown network solution was not feasible for now. He was *not* testing the one-at-a-time "trick" as is being suggested here for the interim, which from what I've been able to gather, may not be problematic.

Votes

Translate

Translate

Report

Report
LEGEND ,
May 24, 2011 May 24, 2011

Copy link to clipboard

Copied

As TK says above, "Use at your own Peril". Adobe specifcally says that use of the catalog on a Network drive is not supported, so personally I wouldn't even fiddle with any of the workarounds, even for single-user use.

Here's just one of many references on adobe.com: http://kb2.adobe.com/cps/406/kb406369...

Votes

Translate

Translate

Report

Report
Mentor ,
May 24, 2011 May 24, 2011

Copy link to clipboard

Copied

Here's the quote:

Quote:

>FWIW, I did actually add a switch (briefly) to allow support of a catalog file on a network share (basically just lifting the block on it) and managed to corrupt the catalog beyond repair (and if you Google around for my name, you'll find I know a few things about repairing catalogs) when testing it under stress conditions. SQLite is fundamentally dependent on sound file locking guarantees to ensure data integrity and network file shares don't cut it.

>So, while it would be (was) be easy to "just allow it" for power users, I'd basically be committing myself to spending all my time helping people whose catalogs were damaged when their network hiccuped at the wrong moment.

>Which unfortunately means a robust catalog on a network share feature is much harder and more risky than it seems on the surface without even getting into the multiple simultaneous users aspect.

>Dan Tull
Lightroom QE
Adobe Systems

Votes

Translate

Translate

Report

Report
LEGEND ,
May 24, 2011 May 24, 2011

Copy link to clipboard

Copied

This is about the same level of uncertainty I discovered a couple of years ago for another use of SQLite. Thought the SQLite authors refer to "reported" problems of the Windows locking primitives, I found supposed Windows experts dismissing such problems when the server side was implemented by Microsoft, as opposed to a third party. We don't know the details of Dan Tull's experiments -- were they with a Windows client, a Windows file server, or some other NAS common in large companies? Did they invovle concurrent accesses or just randomly dropping the network connection?

Given all this, I don't think we can authoritatively state that a Windows 7 client running with a Windows 2003 file server would be problematic. And similarly, I think anyone who experiments with this should be prepapred for possible problems.

Votes

Translate

Translate

Report

Report
Explorer ,
Jun 01, 2011 Jun 01, 2011

Copy link to clipboard

Copied

Please retain a single-user implementation of LR. If you (Adobe) decide to implement a multiuser implementation, make it a separate deliverable.

Most of your customers are unlikely to ever have a need for a multiuser catalog (especially one that supports concurrent update). Please don't foist significantly decreased performance and higher complexity on folks who would receive no benefit from a multiuser implementation.

Dan

Votes

Translate

Translate

Report

Report
Contributor ,
Jun 06, 2011 Jun 06, 2011

Copy link to clipboard

Copied

If I recall correctly, my experiment was a Mac file SMB share with a single Windows XP client. I pulled the cable in the middle of an import and the next time I tried to open the catalog, it was corrupted such that I was unable to fix it in the usual way (doing a SQLite .dump into a new catalog). It wasn't great for performance either, but I didn't investigate that in detail as I was primarily concerned with validating or dispelling concerns about robustness against network failure. Our use of SQLite has changed significantly since then, so it's possible the results of repeating that experiment may be a bit less dire than previously. It's also possible that the (relatively new) WAL mode might be more resilient against this condition. My experiment is more than a little dated at this point. It's probably over 4 years old now.

Votes

Translate

Translate

Report

Report
Community Beginner ,
Jun 08, 2011 Jun 08, 2011

Copy link to clipboard

Copied

It might be worthwhile to consider using a database with a bit more power, such as MySQL.

Votes

Translate

Translate

Report

Report
LEGEND ,
Jun 08, 2011 Jun 08, 2011

Copy link to clipboard

Copied

Any idea what the MySQL commercial license for OEM vendors would cost? If my memory serves me correctly, this option was considered but rejected due to competitive cost concerns (I'm vaguely remembering a post about it on the *other* forum, which you will have a hard time finding since the search is broken there).

Votes

Translate

Translate

Report

Report
Contributor ,
Jun 08, 2011 Jun 08, 2011

Copy link to clipboard

Copied

Cost was never among the reasons I've heard for not using MySQL.

Votes

Translate

Translate

Report

Report
LEGEND ,
Jun 08, 2011 Jun 08, 2011

Copy link to clipboard

Copied

I thought I remembered that's what Jeff Schewe was claiming. I could be remembering wrong (or maybe he was wrong...).

I'd be interested in what reasons you have heard, if you could & would....

Votes

Translate

Translate

Report

Report
LEGEND ,
Jul 21, 2011 Jul 21, 2011

Copy link to clipboard

Copied

Would love to see this functionality implemented. With multiple machines for capture/editing, a shared catalog on a NAS or server is an ideal situation (and saves from having to move a portable drive between machines with the catalog stored on it).

Votes

Translate

Translate

Report

Report
LEGEND ,
Jul 21, 2011 Jul 21, 2011

Copy link to clipboard

Copied

Last year, I submitted a feature request that was received by Adobe to implement a multi-user version of Lightroom. In this forum, I discovered that the reason this has not been implemented is that the underlying database is SQLite which does not effectively imlement record-level locking. Also a comment given for not considering the now much more standard MySQL was potential cost...but that was dismissed in a subsequent comment.

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.

Votes

Translate

Translate

Report

Report
Contributor ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

If we were to create a multi-user system for Lightroom, the database would be unlikely to be the exposed interface anyway. The exposed layer would probably be at a higher level than that (web service-like, regardless of the protocol particulars).

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. 🙂

Votes

Translate

Translate

Report

Report
Contributor ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

Thanks Dan for clarifying some of the issues involved.

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

Votes

Translate

Translate

Report

Report
Mentor ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

"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. "

Since the previews can be dozens or hundreds of gigabytes and since they could easily represent tens or hundreds of hours of CPU rendering time, this might not be all that practical for a "client" system.

Votes

Translate

Translate

Report

Report
Explorer ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

Exactly! I don't need a multi-user-environment but just an easier way of synching my catalogue between desktop and laptop computer. Right now, the only way I can do this is: Before I take my laptop somewhere, I synch my LR catalogue from my desktop to my laptop so it matches it exactly. Then I can work with LR on my laptop. After that, I sync my laptop's catalogue back to my desktop and continue to work there. So, every time I switch computers, I need to sync my catalogue.
It would just be so much easier, if there was a sync feature in Lightroom that would allow to sync and contribute in both directions (let's say, for example by keeping always the most recent edits of both machines).

Cheers,

Timo

Votes

Translate

Translate

Report

Report
Explorer ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

Totally agree with that... it's much more about being able to seamlessly switch computers. I've managed this by using synctoy between PC's but that always made me nervous. I'm trying to see if I can get a dropbox based solution to do the trick.

Anyway, a fully integration "move everything to laptop" button would be great.

Votes

Translate

Translate

Report

Report
Contributor ,
Jul 22, 2011 Jul 22, 2011

Copy link to clipboard

Copied

Jay,

Good point to consider for the Multi-user use case. Even then especially when you are edting most of the your work is going to be local to the client system you are on. You really don't want to have the client constantly updating the previews for every edit. That's what I was thinking about.

To your point there should be a way to "release" work back to the server that would also update the server previews so that additional clients would not have to re-render finished work just to browse the image database.

Votes

Translate

Translate

Report

Report
Guest
Oct 05, 2011 Oct 05, 2011

Copy link to clipboard

Copied

I don't have a need for a multi-user catalog, but a multi-computer catalog would sure be handy. Sometimes I want to do some quick edits while sitting in the family room with my laptop. For more serious editing sessions, though, I'll be on my desktop. It would be nice to have the same files, and the same catalog, accessible from both.

Votes

Translate

Translate

Report

Report
Guest
Oct 15, 2011 Oct 15, 2011

Copy link to clipboard

Copied

It worked for me, however the performance was not very good. In the end I decided to keep the library on my notebook since that is where I do all of the editing, and to only keep the actual photos on the server. This also meant that the thumbnails are not stored on the server but on the laptop, and that made a huge difference. However I am using WiFi, so that is probably the reason why it is so slow over the network.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 15, 2011 Oct 15, 2011

Copy link to clipboard

Copied

So, is the bottom line that Adobe is not currently considering creating a multi-user version of Lightroom? Or is it under consideration for a future version?

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 15, 2011 Oct 15, 2011

Copy link to clipboard

Copied

It seems to me that lots of reasons have been given for why a multiuser version has not been accomplished in the past. That said, a rebuild of Lightroom to make it multi-user would move Lightroom from a niche to a major consideration for small to large organizations where data synchronization are essential for any organization wide solutions. I think Adobe should consider how this will improve its competitive postion in the market and go for this major increase in functionality.

Votes

Translate

Translate

Report

Report
LEGEND ,
Oct 15, 2011 Oct 15, 2011

Copy link to clipboard

Copied

Thank you! - I wonder how it would be with a good solid "n"-type wi-fi connection (designed for wireless HD video streaming...) - dunno how quick those are for frequent little tidbits, like misc quick-accesses to catalog...

Votes

Translate

Translate

Report

Report