One of those heart in throat errors, importing to NAS disconnects

[rebop]

Lightroom Version Number

15.5

Operating System

1. macOS 15 Sequoia

OK this happened one version ago or so and I hoped would fix in this current version since the same hardware worked fine a few months ago. Guessing, but now on 15.5. I would say last working version was 15.3, but *might* have been 15.2. Let's so three months ago was definitely working/ If have to nail the version(s) affected, I can try.

BUT, importing from CF card to my NAS. Fast reader, fast cable. Somewhere in the middle of importing 344 images, all CR3, the NAS disconnects, Not just LRc, but from the network!!LRc fails on the import and a lot of work to clean up and try again. Just importing again and "ignoring suspected duplicates" can cause a mess.

Once that is done., I try to import from my second card and change stating number. That can fail as well - now even tougher to tidy up and try again. eventually, I get it all, but two card, 457 images just took maybe an hour and 20 minutes to import into a folder ion my NAS (Synology DS 923+).

Not sure where to begin. And hard to test until my next shoot. I have not seen the NAS disconnect with any other program including large backups of my computer to the NAS.,

Appreciate thoughts and advice.

 

[Gnits]

I notice that there were several bug fixes specific to NAS in the most recent update.

I use NAS as an extra layer of backup... I gave up using NAS as an active part of my LrC live system. The reasons are twofold.. 1. NAS was too slow for me to use , especially when importing images from say Card or a NAS disk target, but also in general usage . 2. I realised I have little control over what traffic is running on my network.. as everyone is using WiFi now on their mobiles and I have a lot of smart devices (incl security, video cameras, various automations).

I am keen to go back to NAS at some point in the future but only when I can install a robust network running at least 10Kbps ( and perhaps a faster than that , dedicated link between my main PC and the NAS). My computer's linked to my network are all wired Ethernet , no wireless links.. but I also have a 3 node wireless mesh network to cater for mobile users and smart devices).

In your case, I would be tempted to import my images to local fast storage and then have a process to archive this to NAS as a monthly or quarterly task. I accept that might not be practical or attractive for your workflow.

 

[Swingman]

OK this happened one version ago or so and I hoped would fix in this current version since the same hardware worked fine a few months ago. Guessing, but now on 15.5. I would say last working version was 15.3, but *might* have been 15.2. Let's so three months ago was definitely working/ If have to nail the version(s) affected, I can try.

BUT, importing from CF card to my NAS. Fast reader, fast cable. Somewhere in the middle of importing 344 images, all CR3, the NAS disconnects, Not just LRc, but from the network!!LRc fails on the import and a lot of work to clean up and try again. Just importing again and "ignoring suspected duplicates" can cause a mess.

Once that is done., I try to import from my second card and change stating number. That can fail as well - now even tougher to tidy up and try again. eventually, I get it all, but two card, 457 images just took maybe an hour and 20 minutes to import into a folder ion my NAS (Synology DS 923+).

Not sure where to begin. And hard to test until my next shoot. I have not seen the NAS disconnect with any other program including large backups of my computer to the NAS.,

Appreciate thoughts and advice.

I assume you haven’t installed any additional memory or using any fast Nvme disks. If you can physically touch your synology, why not use a card reader and physically connect using front USB 3.2 port?

 

[rebop]

I don;t think the connection is the issue. I'm on 2.5 GB Ethernet. I can copy the card to my desktop, then import and same issue. It MAY be amount of images dependent. Sometime 100-150 images will work while 350 might fail and usually around 78 images.

Variables? Change in LRc or my dock connecting the Mac to NAS via ethernet. Always worked for years exactly how I use it now. Dock is 3 months old. Might be either. Definitively an issue.

 

[Gnits]

Can you copy the card to the NAS .. using say Finder.. or a copy / synch utility. Ie stress test the NAS connection but outside of LrC.

I am not knowledgeable enough about networks.. vg that you have 2.5 Gbps.. but there are all sorts of protocols and stuff going on a network which are absent from disk i/o to a local drive.

Personally, I was shocked at how slow the i/o was between my LrC app and the NAS.. but I did not do a deep dive at the time.. And I was keeping my Catalog on a fast internal drive.

 

[Swingman]

Can you copy the card to the NAS .. using say Finder.. or a copy / synch utility. Ie stress test the NAS connection but outside of LrC.

I am not knowledgeable enough about networks.. vg that you have 2.5 Gbps.. but there are all sorts of protocols and stuff going on a network which are absent from disk i/o to a local drive.

Personally, I was shocked at how slow the i/o was between my LrC app and the NAS.. but I did not do a deep dive at the time.. And I was keeping my Catalog on a fast internal drive.

Matt, You are right that networking systems are more complex with many competing non-complimentary cables, ports, standards. I don’t think all softwares or hardware are able to fully utilise these and fall into lowest denominator. Apple tries to keep its noses clean by having thunderbolt connections to overcome most mis-match systems in use.
One of the culprits is the Microsoft, by allowing all and sundry to use their own systems.

 

[rebop]

I have a synchronizing utility that runs something between NAS and Computer most every night. For example syncing a COPY of my home directory from computer to NAS so I always have that. Reads dozens and dozens of GB then last night, copied and replaced 2.5GB. Much more that the amount being handled in LRc. No issues. I have not had a problem with any app other than LRc. Not definitive that is the issue, but looks likely. And only occurs during IMPORT. Should be a clue somehow.

I copy to the NAS leaving files on the card. Rename, add keywords. Put in a folder by date. No develop settings.

The connection between NAS and computer is not slow.

 

[Gnits]

I have no personal experience of 2.5GB but expect it makes a good diff. Good that Synch job works... which does bring the focus back to LrC or the Dock.

I remember seeing the bandwith and latency tests when first use of fibre as backbone in a large bank hq building.. yikes.. unbelievable at the time when I was used to dealing with low speed wan links.

Lots of people using LrC use NAS devices, only occasional posts here.

Can you test an import where you do not get LrC to build previews... just to reduce the overall LrC disk i/o.

 

[rebop]

Interesting test. Will have to wait for my next shoot. And then, after import, how to tell LRc to build the 1:1's??

And recall, this worked for a year plus before the errors and disconnect.

 

[Gnits]

Worked for a year.. agreed..

but the recent LrC upgrades probably changed a lot of the internal processing, as structural changes to handling Ai related cache files..

Easy for developers to trip over something or forget they need to cater for networked drives..

Just looking for clues at this stage .. and reducing i/o is just a stab at finding something useful.

 

[rebop]

And appreciated. I could do a test import then delete all those files. May later on. First thing now is to process and still 427 shots to cull and proecess

Maybe do that test tonight.

If the dock was not new, would be easy to definitively blame LRc. But then no other operation disconnects the NAS. And LRc freezes before the OS says NAS dismounted.

 

[bcarlson78248]

My suspicion is that somewhere in the protocol stream there are buffers that fill up after the transfer has been running for a while, and then the retransmissions start to kill the throughput.

Many years ago I worked for a program office that was measuring throughput for sending data through satellite links, and they also wanted to determine how much additional delay we would get from adding encryption.

Bottom line issue was that our old network interfaces were difficult to “tune” for the timing difference with a satellite link (much more delay). At at least one protocol level we had many timeouts, followed by retransmission of packets that appeared to be lost (but they were not lost, and just had more delay than expected). The final, unexpected solution was when we installed an encryption device at each end point. The device was a newer design and it could easily be adjusted to compensate for the satellite delays. All the old interfaces worked fine because they only had to operate correctly with the encryptor, and it took care of the satellite link. Total throughput increased significantly.

 

[rebop]

Interesting. Which reminded me of a detail....

After first failure, attempt to import again with "disregard suspected duplicates" is out of what. LRc really does not know what came through completely and what did not.

 

[clee01l]

I am of the opinion that NAS volumes should not be used for Primary Lightroom Storage In particular Synology NAS have presented problems in the past.
Here is a documented bug over two years old.
https://community.adobe.com/bug-rep...that-reside-on-nas-drive-to-be-deleted-662066

 

[rebop]

Just posed this to Claude AI. Fascinating. In first swipe at it ruled out the card reader and likely, (likely!!) Lightroom. Its fascinating and long. I will post it if folks want and mods agree. If not, for now, we suspect the DOCK and have a test to confirm that. Or at least refine what we believe to be happening.

 

[Gnits]

somewhere in the protocol stream there are buffers that fill up after the transfer has been running for a while, and then the retransmissions start to kill the throughput.

I think this is close to the mark and accept this may have been at play for my NAS attempt. Further, I am not sure of the topology of your network. Commercial networks tend to have Quality Of Service configured to separate critical traffic from background traffic.

One of the things I would try is place the images on the NAS , where you plan to leave them ( using say Finder or equivalent tool), and then use the Add mode to import to LrC... again trying minimise the amount of file transfers to be completed over the network by LrC. I would run building previews as a batch, maybe overnight, process. You may have already tried this. I have not absorbed all the recent posts, will revisit in the morning.

 

[camner]

I don;t think the connection is the issue. I'm on 2.5 GB Ethernet. I can copy the card to my desktop, then import and same issue. It MAY be amount of images dependent. Sometime 100-150 images will work while 350 might fail and usually around 78 images.

Variables? Change in LRc or my dock connecting the Mac to NAS via ethernet. Always worked for years exactly how I use it now. Dock is 3 months old. Might be either. Definitively an issue.

Unfortunately, in my experience not all docks and all officially “compatible” devices play well together. And I presume you’ve tried connecting the NAS to another port on the dock (if such exists)? Are the cables all the same, or are you using a new cable (perhaps it came with the dock) to connect the new dock to the computer?

 

[rebop]

OK, just did an import from LR to my desktop rather than NAS. NO issues. Then copied from desktop to the NAS. NO ISSUES. So AI says:

That's the key result — 10.56 GB straight through with no hiccup means the dock, hub, and NAS are all fine under sustained load. The hardware chain is cleared. This is a Lightroom-specific problem writing to a network volume, not an Ethernet/hardware problem.

That actually redirects things nicely, because now we're isolating what LRc is doing differently than a plain copy. Import does several things at once that a Finder copy doesn't:

• Copies the raw files
• Renders 1:1 previews (the heaviest part — this reads each full raw and writes a large preview file, over and over, rapid-fire)
• Writes XMP/keyword metadata
• Writes catalog updates

Next test: Do an LRc import to the NAS again, same batch size, but with "Render Previews" set to Minimal (or Embedded & Sidecar) instead of 1:1, and rename/keywording turned off for this test only. If that completes cleanly, it strongly implicates 1:1 preview rendering as the trigger — it's by far the most network-write-intensive part of import, and it's plausible the update changed how/when those preview writes happen against a network catalog or network destination.

If it still freezes even stripped down, the culprit is more likely the import process itself talking to the NAS (catalog location, or just LRc's general handling of a network destination), rather than any one feature.

Will have to try that tonight.

 

[rebop]

This is interesting:

Claude: This turned up something genuinely useful, and it fits your case well.

There's an active, recent Adobe community bug report describing near-identical symptoms: Lightroom Classic import hanging/"Not Responding" with CPU, disk, and network all sitting idle during the freeze, reported on version 15.5, with the import work seemingly stuck on the main UI thread instead of properly using available system resources. That's a strong match for a freeze that isn't caused by your hardware actually failing — it's LRc's import pipeline stalling on its own thread while everything downstream (your dock, hub, NAS) sits there idle waiting, which could easily be misread by macOS as the network share going away.

A couple of other relevant threads back that up:

• Multiple users on recent Lightroom versions and Mac hardware report the same hangs during preview building, photo merge, and import/export — and notably, one user resolved it by rolling back to a specific earlier version (15.2.1), which is a strong signal this is a real regression tied to a specific recent release rather than something environmental.
• A separate case describes Lightroom import from a NAS becoming effectively impossible after the first few thousand images in a session, even though smaller imports work fine — different flavor, but same theme of NAS-destination imports being fragile in current LRc versions.

What this means for your situation: it raises real doubt that this is purely a "1:1 previews are too network-heavy" issue — it may be that LRc's import/preview pipeline itself is buggy right now on recent versions, and writing to a NAS (higher latency than local disk) is just what tips it over into a full freeze rather than a slowdown. Your local import being fast either way (with or without previews) is also consistent with that — the bug seems to specifically bite when a network destination is in the mix.

Bingo. I have 15.5 and would have said it seems to have changed two versions ago. I think this confirms its a LR issue.

 

[Gnits]

I think it is not a coincidence that Adobe had a few specific patches in the most recent LrC updates.

If you can isolate this as an issue and post a bug report report of your findings you might help the overall status of NAS connectivity.

I spotted the reference to the NAS related patches because, although not a current LrC / NAS user, I am sensitive to the status of NAS as an option and would like to have the option to install a fast NAS at a future date.

My plans are delayed due to current spike of memory prices, storage, etc.. and sense that a Thunderbolt enclosure may be my route to migrating from Win to Mac.

 

[rebop]

I found it.

Its fixed.

It was my fault.

I am almost too embarrassed to tell you what it was



The NAS has two ports. One goes to the Verizon router via Ethernet for online access, updates, etc. To email me if a failure, even.
The other 1GB port went to my hub where the dock also connects.

I bought the 10GB upgrade card even though my Macbook will only do 2.5GP. The hub is also 2.5GB. This upgrade in a hidden slot and creates a third Ethernet port.

I connected a new cable from there to hub.


BUT, I never disconnected the other 1GB to hub!! So they were fighting.

I disconnected the 1GB and now the NAS no longer disconnects when importing and creating 1:1 previews It is slower than I recall, but if it doesn't crash., I am very pleased.

And found by accident when trying to go direct from Dock to NAS without the hub to test the hub.

 

[Gnits]

Super that you found the problem.

Do you understand why this suddenly created such a problem.

 

[bcarlson78248]

Gnits - I’m not sure this is relevant, but many years ago we did a study of LAN’s with dual connections to the outside world, and how to manage the traffic. The logical first assumption was to alternate traffic and balance the load between the two paths, and then transition to some type of priority algorithm as the traffic increased. However, we found that the optimal overall scheme was to route all traffic to a single interface until it saturated (I don’t recall how that was determined), and then start sending traffic to the other interface. The analysis determined that the process of comparing the two external interfaces and trying to find a best path did not improve throughout very much at all. YMMV

 

[Gnits]

My #22 post was relief that the problem was so definitely solved.. but wondered what was the trigger / source of the problem as it was stable prior to the issue. Perhaps a recent network wiring connection.

I understand your investigation on optimising network throughput. In the early pre internet / pre tcp/ip there was never enough bandwidth at lan, wan or datacentre level.. and every possible tweak was explored to improve performance.

I think it is incredible that 80Gbps Thunderbolt connections are now possible at retail level... and disappointed that 10Gbps has not become the norm for home network use. Wireless mobile means people have been able to avoid wired networks. That is understandable..

I can kick my decision re a Thunderbolt Ensclosure / NAS decision down the road... but will watch how storage solutions evolve.. especially with the cost of anything related to memory or storage.