Lightroom Classic Sync Files

[matt-thebixlers]

Lightroom Version Number

15.1.1

Operating System

1. macOS 26 Tahoe
2. iPadOS

Hello,

The sync function in Lightroom Classic is taking hours with no apparent progress. It has said "syncing 1 photo" for hours and the cloud storage amount has not changed. I recently opened Lightroom on my iPad for the first time in a while but I have not added any new files. Is there a way to check to see if this is working properly? Thanks in advance for your consideration.

Matt

 

[clee01l]

Completely "off-the-wall" wondering but does the Adobe Cloud scan images/uploads of content they "don't like".

I know that some cloud storage services scan uploaded/stored content for copyright stuff and will close your account if they suspect it (fair number of complaints on some Reddits). What made me wonder is reports some years back in relation to sexualised images where some services were reported to be blocking eg medical images because their analysis identified to much flesh tones.

Just a complete wild idea and I have not experienced any such issues and not read any reports of Adobe scanning content, but wild idea?

I don't see why Adobe would. They are your images and your subscribed space. The images are no public unless you choose to make them so. If there is any filtering on the part of Adobe, it would be here only for the albums made public

 

[Eric1951]

Re: OP's Sync Blocking Images
If you can find a solution I guess at this point you need to decide if it's a robust enough feature for long term use or will the same happen again in a few days/week/months (and probably just at the most inconvenient time.

Without knowledge of the solution, things I'd be trying to investigate are:
1. Copy original file, give a different name, import into LrC and add to sync'd collection and does it sync ie is it the name.

2. Use an external image converter to convert the original into a different format eg if original RAW, convert .jpg with different name and import into LrC to be sync'd and does it sync?

3. Use image processor to cut excerpts of original and store to new file (eg into 2 images one top half and other bottom half) store in new filenames and import to LrC and sync and do they sync?

4. Maybe use an external tool to check and remove any EXIF tags in case any of those are causing the problem.

My limited (maybe incorrect) understanding of the sync. process for images imported into LrC is that LrC generates Smart Preview (or Smart Preview like) versions to actually sync. So guessing on top of my assumption, might be the issue is with the conversion to the format that is sent to the servers or might be the upload to servers that is the issue. Please do correct my misunderstanding if my understanding is correct - I claim no expertise on this.

Thank you so much for your inspiration! I tried deleting the un-synchronise-able files from Lightroom Classic - then reimporting them. A few I changed their names slightly. These then synchronised OK on re-adding them to the relevant collection. Then I tried not even renaming them. These too worked fine. What a happy bunny I am! Not least, because they are all .dng's now, I even got my edits back on re-import. Brilliant. Of course it would be better still if Lightroom wasn't prone to foul-ups of this nature - but at least I now have a fix.

EW

 

[Eric1951]

Thank you so much for your inspiration! I tried deleting the un-synchronise-able files from Lightroom Classic - then reimporting them. A few I changed their names slightly. These then synchronised OK on re-adding them to the relevant collection. Then I tried not even renaming them. These too worked fine. What a happy bunny I am! Not least, because they are all .dng's now, I even got my edits back on re-import. Brilliant. Of course it would be better still if Lightroom wasn't prone to foul-ups of this nature - but at least I now have a fix.

EW

Further! I think I have now worked-out a definitive explanation of what went wrong and why, and how to fix it; which I'm setting out here in case anyone else runs into the same problem.

1. What went wrong. I have recently taken to converting all my RAW files to DNG and have set Catalog Settings > Metadata > "Automatically write changes into XMP". With DNG files this has the effect of writing edits to the file itself (no XMP sidecar created). What seems to have happened is that when I then edited - or re-edited - files already synced to the cloud, LrC got busy saving those edits as I went along, and got confused between newer and older edits as I continued to make adjustments. Hence syncing of these altered files 'hung', did not complete.
2. The answer. To prevent this happening, in the circumstances I describe, do not edit 'DNG+metadata' files whilst actively synced with the cloud - this can most conveniently be achieved by temporarily un-syncing any collection in which they are included. Or edit them before you place them in any collection at all.
If you get caught out with a 'stuck- syncing' file nonetheless, go to the collection(s) in which it is included, right click remove it from that/those collections and take the option also to remove it from the cloud. After the little cloud/syncing icon top right turns a happy green, re-select the file(s) concerned to wanted collection(s) - but in case you want to make any fresh edits, remember first to remove them from the cloud once more.

Hope that helps!

E

 

[clee01l]

1. What went wrong. I have recently taken to converting all my RAW files to DNG and have set Catalog Settings > Metadata > "Automatically write changes into XMP".

The purpose of the XMP side car file is to provide a mechanism for hosting the XMP metadata outside of the proprietary RAW file and the Catalog. There was a bug a few versions back that causes some performance issues and huge catalogs files. I'm not sure if this bug has been fixed. But the general consensus here is that it is un necessary to use the setting "Automatically write changes into XMP." We recommend turning off that feature. For two reasons, First if you write XMP changes into a non proprietary file like DNG, your system backup app is forced to write out a new copy of that file for every time a file of that type is backed up. OTOH, With an XMP sidecar file, you only backup a small text file (the XMP) instead of the larger Image file. The second reason is unnecessary redundancy. All of the metadata stored in the catalog and with sufficient backups of the catalog, you don't need the extra copy of SOME of the metadata stored in the XMP file or header block.

I am of the opinion that converting proprietary RAW file types to DNG is an unnecessary waste of effort. For the reason the Proprietary file types contain manufacturers data that while copied to the DNG header is not used by Lightroom and no longer accessible by future improvements in the manufactures apps. So you really need to keep the proprietary RAW original file. you should never throw it away. So if keeping the proprietary RAW file type do you really need to essentially double your storage ? Some fear that Developers like Adobe will stop supporting older proprietary file types. This has never happened and the oldest proprietary file types (Kodak IIRC) are still supported. Should in the unlikely event that happen in the future, then would be the time to convert that proprietary file type to DNG.

Think of all of the grief you could have saved yourself if you had not created a separate XMP from the catalog and not converted your proprietary files to DNG.

 

[Gnits]

I agree with Cletus.

I regularly get asked by individuals if they should create xmp side car files. I reply… I will turn on the parameter if an individual can put in writing when and how you intend to use such files. No one has yet to give me their personal justification.

Saving files as DNG… probably a more complex 3 dimensional topic… but my raw files from my first camera are still readable by LrC… and always have the option to convert to DNG in the future, so my view is why burn cpu cycles and storage for something I do not need and add an admin overload to everything I do. I prefer to keep my original image files and no longer keep the camera version of jpgs ( because with 170k files in my Library, other than a few when LrC launched… I never used them).

The LrC / Lr Mobile synch system is (imho) still a delicate creature… and I minimise to the max the potential for clogging the LrC cloud pipes with my data.

Everyone’s use case is unique… and there are probably lots of good reasons to save xmp data and or convert to Dngs.

 

[Swingman]

The LrC / Lr Mobile synch system is (imho) still a delicate creature… and I minimise to the max the potential for clogging the LrC cloud pipes with my data.

Matts, I have been using LrM uputil two weeks ago. Now I have sync all of them without any problem. Yesterday I have some issue either LrC. I switched to LrM managed to resolved and immediately all synced properly to LrC. Cletus been using that route for few years.

 

[Gnits]

Hoping it flows for you.

It is depressing the number of synch issues which arise... hopefully a small percentage of the real total.

 

[clee01l]

It is depressing the number of synch issues which arise... hopefully a small percentage of the real total.

I think it depends on which way you are syncing. I think I see more problems when people are trying to complement Classic with Cloudy. Swingman (and I) have all of our originals in the Adobe Cloud. not the other way around

 

[Gnits]

I think it depends on which way you are syncing.

Probably…. but it should not matter. There are real world examples of complex systems which synch around us that work 99.999% of the time.

Just think of an ATM or Credit Card machine. These are designed to work in standalone mode or online mode and synch when connections are broken / reestablished. I have managed large complex ATM networks and could not image the chaos if only a tiny percentage of transaction were problematic. If the LrC LrCloud synch systems were dealing with ATM or credit card transactions it would be fixed inside 24 hours.

I do not know if the issue is a flawed design or buggy software, but in my view it is causing reputational damage. It is the reason I do not use any of the LrCloud apps and I limit synching (one way) from LrC to LrCloud to a few small collections that can either be abandoned or reset without consequences to me and the need to spend hours or days or longer reestablishing the correct synch status.

I admire the patience of people here who have the knowledge and skills and take the time to help trouble shoot these issues on these forums. My complements to you all.

 

[Swingman]

Probably…. but it should not matter. There are real world examples of complex systems which synch around us that work 99.999% of the time.

Just think of an ATM or Credit Card machine. These are designed to work in standalone mode or online mode and synch when connections are broken / reestablished. I have managed large complex ATM networks and could not image the chaos if only a tiny percentage of transaction were problematic. If the LrC LrCloud synch systems were dealing with ATM or credit card transactions it would be fixed inside 24 hours.

I do not know if the issue is a flawed design or buggy software, but in my view it is causing reputational damage. It is the reason I do not use any of the LrCloud apps and I limit synching (one way) from LrC to LrCloud to a few small collections that can either be abandoned or reset without consequences to me and the need to spend hours or days or longer reestablishing the correct synch status.

I admire the patience of people here who have the knowledge and skills and take the time to help trouble shoot these issues on these forums. My complements to you all.

Matt, As someone only using LrC for one week, I have noticed it has lots of bolt-on to add new features over many interactions, thus has resulted in highly sprung software it allow little leave way for the users. Here there not many ways of skinning the cat. As a new user it has been baptism of fire. So far I have only bitten a very small portion of the LrC. It has been all trial or error to master it. I am sure when I start the Develop module I am going to encountered even more. So far only Sync and Maps. Still got about 30% more maps to do.
I also tried reflection removal ( recently lots of post here) on one image. It didn’t work at all. Haha.
I assume for many in this forum that have been using it for many years of iterations, each addition can easily absorbed in their workflow and quirkiness doesn’t come into it.
My main gripe is the selection photo in the loupe or grid as the colour scheme is just like 50 shades of grey (figuratively) different to see clearly. I wish there is a way for user to change the colour in the Preferences.

 

[Gnits]

I think LrC is a massive app and I value it a lot. I also accept its interface has to cope with a massive data model and high level of flexible interactivity. I have been using LrC actively since its first beta version.

Eventually, with accumulated experience , we all find our best way to work with the app. In my view .. it takes months to get to LrC basecamp and the experts here agree that they learn something new every day.

But I regard the Synch issues as vip and it has been too delicate for too long.

I will look at your comment re selection photo later… when I get back to my desk.