[Leica] Questions about using NAS with LR

[Nathan Wajsman]

Thanks for the very clear explanation, Brian. I have a simpler question. Now that I am beginning to travel more again, I want to work on photos when on the road. What I usually do is to create a dedicated small LR catalog on my laptop for the photos I do during the trip. When I come home, I connect the portable disc to my desktop computer and use the “import from another catalog” command in LR to get the travel photos into my normal LR catalog.

Could I instead synch the main LR catalog to a portable drive, add to it and work on it during the trip, and then synch back to the main catalog when I return? 

Cheers,
Nathan

Nathan Wajsman
photo at frozenlight.eu

http://www.fotocycle.dk/paws
http://www.greatpix.eu
http://www.frozenlight.eu

YNWA




> On 9 Oct 2021, at 02:25, Brian Reid <reid at mejac.carlsbad.ca.us> wrote:
> 
> The real problem with a shared master Lightroom catalog is that the Lightroom software internally uses "lazy evaluation" for as much as it can. Shared-master index catalogs are difficult under any circumstances, but Lightroom makes it worse by postponing as much processing as it can. The software engineers chose this technique to make the app seem faster.
> 
> You have certainly seen one kind of lazy evaluation when you export a photo in LR. It doesn't export right away. It launches the export process and then returns to ask you what you'd like to do next. If you try to quit the Lightroom app before the export is done, it scolds you and tells you to wait.
> 
> Much of the other processing is also "lazy", which is to say that it doesn't happen when you ask for it but rather happens when LR gets around to it. The most insidious effect here is if the process that is running lazily in the background needs to do semaphore locking on the master catalog, and there is a siphon running somewhere that is moving the catalog file somewhere else, the locks will get replicated to the destination.
> 
> Semaphore locking is the core technology of multicore/multi-thread/multi-processor computing. Here is the usual classroom explanation, showing two processes that are each trying to add 1 to a number.
> 
> Process 1:
>   get the number from memory
>   add 1 to it
>   store it back into memory
> 
> Process 2:
>   get the number from memory
>   add 1 to it
>   store it back into memory
> 
> The problem arises if those two processes are running concurrently in separate threads. It can look like this:
> 
> Process 1:                       Process 2:
>   get the number from memory        get the number from memory
>   add 1 to it                       add 1 to it
>   store it back into memory         store it back into memory
> 
> Often this results in only one addition, not two. So you have to lock the memory:
> 
>   check to see if the memory is locked. If it is locked, then wait.
>   lock the memory location
>   get the number from memory
>   add 1 to it
>   store it back into memory
>   unlock the memory location
> 
> The "if it is locked, then wait" was the topic of at least a dozen PhD dissertations in computer science in the 1980s. The famous Mac "spinning pizza of death" is what shows on your screen when a process is waiting for a lock on something bigger than a single number. Usually the spinning pizza shows it waiting for an entire file to be unlocked.
> 
> If you are so unlucky as to copy a master catalog to another place when there is a file lock set, then the next time LR ties to use the copied master, it will see the lock in the copy and wait for it to cleaR. But that wait will be forever, because the would-be unlocker doesn't know that the copy has been made and doesn't notify that destination.
> 
> Eternal SPOD.
> 
> _______________________________________________
> Leica Users Group.
> See http://leica-users.org/mailman/listinfo/lug for more information