[Leica] Questions about using NAS with LR

[photo at frozenlight.eu (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