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

Report · May 01, 2011

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.

Report · Oct 15, 2011

SQLite makes use of frequent, small I/O operations, and the performance of those can get killed by network latency (time to send a single packet). Wireless networks, even N networks, have much higher latency than wired networks, and thus I'd bet good money that LR catalog performance would suffer over an N network. Wifi N is reasonably good at video streaming, because packet latency doesn't matter, only total throughput (bandwidth).

Photshop Elements (since v6) also uses SQLite for its catalogs, and I tried an experiment running it over a 100Mb Wifi network. Performance was horrible.

Report · Oct 15, 2011

feature request for this site: ability to "gold-star" comments as well as original replies 😉

Report · Oct 15, 2011

Have you guys looked at Adobe Carousel? It's the start of multi-user, multi-computer, multi-device workflow.

Report · Oct 15, 2011

Yes, that's my experience too. Performance isn't very good, eventhough I am using a N network. Plugging in the external drive helps a lot, but having the files on an internal hard drive... (esp. if it is fast...). Only do it if you really have to, and you could try to (automatically?) sync the catalog file (+ thumbnails perhaps), just make sure the location of the catalog as well as the location of the photos stays the same on both computers. And yeah, having the files on the computer you usually work with helps too, since otherwise the loading of the RAW files will take a while too (depending on the network of course, with a 1 Gbit connection it might not be that much of an issue anymore).

Report · Oct 15, 2011

Yikes. Carousel doesn't even come close to addressing the needs of this feature request. It's jpg only and it's a separate program. Either of those are deal breakers. Together....

Report · Oct 15, 2011

Remember, I said "It's the start..."

Report · Oct 15, 2011

Check out the last paragraph of this blog post: http://blogs.adobe.com/photoshopdotco...

Report · Oct 15, 2011

Yes, I know, and I'm honestly trying not to be too negative here, but Carousel will never be the solution to this problem. I shot 6 GB of images this afternoon, 6 GB yesterday, and 30 GB on Thursday. I need a solution that allows me to work from my laptop or my desktop across my LAN. Uploading all that data to a cloud services to work from is simply not feasible.

Report · Oct 15, 2011

I wonder if it would be possible to implemented localized "cloud-lets". i.e. take advantage of Carousel/Cloud software technology fitted for local net.

Report · Oct 16, 2011

With the caveat that I don't work on the Carousel team (though I know several of its members), nothing it does would preclude P2P operation of the sync'ing protocol. At least for my part, it is of no interest to me until there is a P2P version since I don't really _want_ all my photos in the cloud even upstream bandwidth didn't make the upload process impractical.

Report · Oct 16, 2011

So, if I got it right, in a few years or so, we may actually see Carousel be the multi-user version of Lightroom... in the global cloud, or local-cloud/p2p/lan...(?)

Report · Oct 16, 2011

That's exactly my thought Dan!

Report · Oct 16, 2011

Same here. I think I'd rather have a locally installed Lightroom (on all the computers I want to use), but with a cloudish backend, that might sync all the settings + when necessary the files I want to be working on. Or if I'm on the go I could press a sync button and it sends the files to a fileserver running at home (or in the cloud). But such a system would have to be very flexible, which could make it rather confusing to use I suppose?

I can see myself using a backup/cloud service run by Adobe, where all my photos are stored (encrypted), something like Backblaze/Mozy/Carbonite/..., but with a photography focus and a tighter integration into Lightroom (it should be competitively priced (perhaps slightly above the aforementioned services, when you have a Lightroom license there are discounts or vice versa, ...) and offer backups of other files too... especially media files, but also documents). Perhaps Acrobat.com could be integrated into it, so that when we have backed up our Word documents that way we can, online, access these files and modify them, Acrobat.com documents are automatically synced with your computer too, ... I think that would be really awesome.

Report · Oct 17, 2011

Hey Jeff. I'm excited about the potential of Carousel. Recognizing that it's just "a start" I'm holding back my criticisms to this--I think it would have been nice (speaking personally) if the the "start" had been a feature set more geared towards lightroom's serious or pro users. What I mean by this is addressing RAW file workflow, and as Sean Mentioned, more of a LAN based synching solution.

Carousel seems like and circle on Adobe's big Venn diagram of partially overlapping products; and it certainly introduces some features and Ideas that will satisfy certain types of users. But for me, there's just not a point in engaging yet and therefore, difficult to give constructive feedback.

Report · Oct 17, 2011

Sure. I knew the *current* file support angle of Carousel would be a deal-breaker for most pros, but the synchronization aspect would show that we're investing in multi-user, multi-computer, multi-device workflows. Because Carousel is heavily tied to Tablets and Phones, raw file support wasn't in the cards for that workflow with those devices as 1.0 release - but realize that what's underneath is a subset of Adobe Camera Raw (the subset that these devices can drive in a performant manner) and that the rest of the engine can be engaged later on. Hopefully that gives you an idea of the trajectory they're on.

Report · Nov 14, 2011

Adobe already has this programmed for Bridge using MYSQL and full access control and locking permissions. (They did a too complicated job in my opinion) SQlite can literally be emulated on top of mysql. The only piece would be to add a few lines of code that point lightroom to a TCP socket and network share containing the files; and have a little listening port that keeps your local copy of LR up to date on what files other users have clicked on. (or that could just be part of the sqlite db presented to the client) The "server" could be any dumb sql backend + sqlite emulator layer + a file store. All the "processing" could be done by client computers at ingest and outclick. If you want to dumb it down even more, use some userland Fuse implementation of SQL so Lightroom doesn't even have to know it's going over TCP. You would have to optimize it.

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

Report · Nov 29, 2011

I don't really want to share a catalog, because the laptop won't be attached to the network most of the time. A shared catalog would be OK as long as each computer keeps a copy of the preview files, and changes to develop and metadata are only permitted when the machine is connected to the network. But I do need to be able to reconcile the same image on two computers.

There are ways of doing it without sharing the catalog - basically things to help me instigate a regime of self-discipline. Colour coding of folders in Lightroom (this has already been discussed), and/or the ability to lock/unlock folders would help greatly, so that I can more easily keep track of which images have been 'sent' to the desktop - then I know not to do any more adjustments or metadata on the laptop.

Another requirement is to be able to export a collection (from the laptop) in a way which only exports membership of that collection, instead of overwriting all the metadata in the target catalog (on the desktop), because I sometimes do a selection on the laptop after the images have 'gone' to the desktop - where they may have been added to other collections and may have had more develop work done. I don't want to clutter the catalog with loads of virtual copies either.

Patrick Cunningham

Report · Dec 01, 2011

Are you guys (Adobe) working on a solution to allow Lightroom to work from a networked hardrive?
Seems like an obvious next step, so places like my studio can run multiple machines and reference the same catalog...

Report · Dec 02, 2011

I think there is really a need for a network catalog for multi-computer usage.
We have the usb harddrive solution but it more a workaround.

Report · Dec 12, 2011

I see where this will probably boil down to a 'multi-user' vs. 'Multi-machine' issue. Not being a programmer, this sounds difficult to easily satisfy all users. Large/small portrait studios would most likely only be working on one client's folder of images at a time. e.g. downloading and first edits. I doubt 2 or three employees would be doing the same job to the same client at a time.

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.

Report · Dec 12, 2011

I see three scenarios:
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.

Report · Dec 12, 2011

Sounds easy, but the beauty of software that's user friendly is usually very difficult to implement, so I guess LR will just remain a one machine software.........

Report · Dec 21, 2011

The one machine restriction is ridiculous. Just drop a lock file into the folder so that only 1 instance of lightroom can access the catalog and you're done. Don't need multi user I just want my catalog on the network so it's backed up and accessible from anywhere.

Report · Dec 21, 2011

A lock file wouldn't address the underlying issue of feared database corruption that might result when accessing a SQLite database from a network drive. See the discussion earlier in this thread for details -- there's a reasonable belief, not backed up by recent testing, that networked LR SQLite databases can get corrupted with at least some combinations of clients and servers.

If you want to live dangerously, you can trick LR into thinking a networked catalog is on a direct-attached disk by using symbolic links.

Report · Dec 21, 2011

I've been trying to figure out how to do this with symbolic links.
Can you provide any more detail on how to set that up.
I'm assuming this solution is for a Mac as Windows doesn't have symbolic links.
(which is perfect for me)

I don't see how the database could become corrupted unless the network drive becomes disconnected while the database is being accessed.

Our whole workflow runs across a network without a hitch. I can't see how this could be an issue for a single user database.

FYI I have a computer engineering degree and have quite a bit of experience with databases and network applications.

Going through the SQlite readme & FAQs seems to indicate that the locking problems all relate to multiple processes (concurrently) accessing the database. This shouldn't be an issue if a lock file is used as a gate to prevent another process from gaining access to the database until the lock is deleted. I'll admit that I haven't read everything written but this is what I have found so far.

The issues of the OS not flushing buffers to disk or disks reporting that the data has been written when it actually hasn't are common to a local disk as well as on the server. Of course there could be corruption if a network goes down, the server crashes, etc just as the database is being written. That problem exists with any application