@GTPhotographyNY, see here: https://community.adobe.com/t5/lightroom-classic-discussions/p-ai-masks-require-updating-and-or-disappear/m-p/15514958#M414181  ... View more

A big mistake on my part: Jao was wrong about the location of the photo but quite correct in his second instruction to set the tracklog time offset to 1 hour.   When you do that:     then LR's Auto-Tag correctly tags the location of the photo:     I misread the contents of the .gpx file for 2005:09:23.  I apologize for the confusion.   The Geotag Photos Pro desktop app uses the method I described in option 1 above, assuming the camera clock was set to the time zone of the GPS track. The app also offers a Fix Camera Time command, which accomplishes the same end as LR's Set Tracklog Time Offset. ... View more

@Millie25437294jyyx, if you share a problem photo, we can see if the issue is specific to your computer or occurs on other installations, and file a bug report as appropriate.  If the forum won't let you attach the file here, upload it to Wetransfer, Dropbox, Google Drive or similar free service and post the sharing link here. ... View more

I don't see any clues in System Info.   Have you enabled the option Catalog Settings > Metadata > Automatically Write Changtes Into XMP? ... View more

Try disabling Automatically Write Changes Into XMP. If you use Denoise in conjunction with that option, a bug acknowledged by Adobe causes these symptoms: https://community.adobe.com/t5/lightroom-classic-bugs/p-automatically-write-changes-to-xmp-can-t-be-...   But even if you don't use Denoise, there are some recent reports here of Automatically Write Changes causing similar symptoms. Adobe recommends turning it off: https://helpx.adobe.com/lightroom-classic/kb/optimize-performance-lightroom.html#LeaveautowriteXMPtu...   I prefer having that option enabled, and it worked well for me for 15 years, but with this recent bug (and a couple others), I've disabled it. We won't know whether Adobe will fix this until they do (they rarely indicate ahead of time). ... View more

"I have read that Adobe retains the right to mine private images uploaded to their cloud for use by their AI tools and possibly other purposes."   What you read is incorrect. Adobe says:   https://www.adobe.com/products/firefly.html#commercially-safe-creative-ai "Adobe does not train Firefly on customer content or content mined from the web. We train our models only on content where we have permission or rights to prevent it from creating content that infringes copyright or intellectual property rights." ... View more

The Folder Publisher plugin is your best bet. ... View more

"However, the main issue is the slowness in loading images when sorting through them - when going back and forth through unedited images during the selection process."   Definitely try disabling Automatically Write Changes Into XMP, as dj_paige indicated. If you use Denoise in conjunction with that option, a bug acknowledged by Adobe causes these symptoms: https://community.adobe.com/t5/lightroom-classic-bugs/p-automatically-write-changes-to-xmp-can-t-be-used-with-denoise-on-large-numbers-of-photos/idi-p/15393188   But even if you don't use Denoise, there are some reports here of Automatically Write Changes causing similar symptoms. Adobe recommends turning it off: https://helpx.adobe.com/lightroom-classic/kb/optimize-performance-lightroom.html#LeaveautowriteXMPturnedoff   I prefer having that option enabled, and it worked well for me for 15 years, but with this recent bug (and a couple others), I've disabled it. ... View more

"Images take far too long to load in Develop view, causing major disruptions to the workflow."   One cause of this: Have you enabled Catalog Settings > Metadata > Automatically Write Changes Into XMP? ... View more

Do you have the option Catalog Settings > Metadata > Automatically Write Changes Into XMP enabled?   ... View more

Please do the LR menu command Help > System Info and copy/paste the entire contents here so we can see exactly which versions of hardware and software LR thinks you're running and important LR options that are set. ... View more

See steps 6 and 8 of this FAQ: https://www.lightroomqueen.com/community/threads/faq-where-are-my-develop-presets.50140/ ... View more

"Why would Map module's Auto-Tag make any assumptions about when a photo was taken? It has a capture time on the camera and date / times on the gpx file, why doesn't it simply match the pair since both should be within the same time zone (if appropriate) and should be synched? It trying to adjust for the time on the computer doesn't make any sense, especially if no time zone is set on the camera."   Here are the issues to be considered:   - The GPX standard records times in UTC, not local time. (The time zones annotated in your .gpx file are non-standard.)   - As Jao discussed before, most non-phone cameras don't record time zones with the capture date/times.    - Many (most?) people forget to change their camera clocks when they travel, fixing the capture times when they import the photos into LR. I'm often geotagging my photos in LR based on a wearable GPS device, and I often forget to change my clock, so the capture times are often off (e.g. by 1 - 3 hours).   So to match a time-zone-less capture date/time in a photo with the UTC entries in a GPX track log, LR needs to know or guess the time zone of the camera's clock and/or be able to translate the UTC log entries to a time zone. Some options:   1. LR could assume the camera clock is properly set to local time where the photo was taken. It could use a well-maintained open-source package to translate the GPS coordinates in the track log to time zones and then translate the log's UTC times to local time. This is harder than you might think. The boundaries of time zones are often complicated, and the politically defined rules for daylight savings time (summer time) vary widely and change over the years. When the Map module was implemented over 15 years ago, the package had lots of errors in its data files. But it's gotten much better in recent years but it's still not 100% correct, especially in parts of the world that are popular with "world travelers".   With this method, a user who forgot to change their clock would get incorrect matches and might not notice immediately.   But another source of error would occur at time-zone boundaries. I've often driven across the boundary between MST (Utah) and PST (Nevada). If I'm taking photos on a road trip, a single track log could contain entries for 09:00 MST and 09:00 PST, separated by an hour of driving. Which should be used to match a time-zone-less camera time of 09:00?  While a less-common edge case, people cross time zone boundaries all the time in some parts of the world.  LR should handle this edge case gracefully.   2. After importing photos into LR, the user could give a Map module command to specify their time zone or to specify the time zones of the track log. This isn't much different than the Map module's Set Tracklog Time Offset.   3. (The current behavior) LR can assume the camera clock is in the same time zone as the computer running LR. This handles the most common case when the photos were taken in that time zone, and it handles the case when they were taken in another time zone but the user forgot to change the clock. But it obviously fails when the user travels, correctly changes the clock, and then imports the photos with the computer in another time zone.   The current behavior is far from ideal (and the documentation in the UI and the help is horrible), but it has the virtue of simplicity compared to option 1. ... View more

"The photo I sent you was taken in Radda at 9:20."   For the other photos taken in Radda that LR correctly located on the map, what does LR show in the Metadata panel for their full capture date/time? ... View more

See this article for a number of different options: https://www.lightroomqueen.com/how-to-lightroom-catalog-multiple-computers/ ... View more

I forgot to ask: What are the dates/times shown in LR for nearby photos in Radda in Chianti that had correctly assigned GPS coordinates? ... View more

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]   I don't agree with Jao's analysis. The issue is not caused by setting the wrong time-zone offset in the Map module. Rather, the capture time recorded in the photo doesn't match up with the track points in the track log where the photo was actually taken.  Changing the track log's time-zone offset in the Map module won't assign the correct coordinates to the photo, since its capture time is about 23 hours 20 minutes later than the track points in the track log closest to the actual location.   Unless the camera's clock was set wrong by 23 hours 20 minutes, I don't know what accounts for this discrepancy. LR is operating correctly with this photo and track log.   * * *   Jack said the photo was taken at Radda in Chianti. Google Street View shows the photo was taken in Radda in Chianti at coordinates 43.4871447, 11.3756591: https://www.google.com/maps/place/53017+Radda+in+Chianti+Province+of+Siena,+Italy/@43.4871447,11.3756591,3a,75y,292.25h,94.19t/data=!3m7!1e1!3m5!1s_NPaejPslIMOwzeVvdWauA!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fcb_client%3Dmaps_sv.tactile%26w%3D900%26h%3D600%26pitch%3D-4.189999999999998%26panoid%3D_NPaejPslIMOwzeVvdWauA%26yaw%3D292.25!7i16384!8i8192!4m7!3m6!1s0x132bcb1b7d5656eb:0xd32774d27b17279!8m2!3d43.4868759!4d11.3757607!10e5!16s%2Fg%2F119vycsl9?entry=ttu&g_ep=EgoyMDI1MTAwMS4wIKXMDSoASAFQAw%3D%3D      (This is much different than where Jao indicated in Siena.)  The closest points in the track log to the Street View coordinates are:   <trkpt lat="43.486721" lon="11.374245"><ele>542.238647</ele><time>2025-09-22T07:57:25Z</time></trkpt> <trkpt lat="43.486721" lon="11.374245"><ele>542.238647</ele><time>2025-09-22T08:01:26Z</time></trkpt> <trkpt lat="43.486919" lon="11.375193"><ele>535.415344</ele><time>2025-09-22T08:02:26Z</time></trkpt> <trkpt lat="43.487080" lon="11.375761"><ele>542.048645</ele><time>2025-09-22T08:03:26Z</time></trkpt>   Here's LR's Map showing that portion of the track log along with coordinates provided by Google Street View:     The two times displayed in Map by hovering over the track points are in the time zone of the computer running LR, which is BST = UTC+1 in this case. They correspond to the UTC times recorded for those points in the track log, 7:57:25Z and 8:03:26Z.     Italy is in Central European Summer Time (CEST, UTC+2), so those trackpoint date/times are:   2025:09:22 9:57:25 UTC+2 2025:09:22 10:03:26 UTC+2   The capture time recorded in the photo is 2025:09:23 09:20:23.11 (with no time zone recorded or used by LR). It is about 23 hours and 20 minutes later than the track points (CEST).  This indicates the issue wasn't caused by setting the wrong day in the camera or picking the wrong hourly time-zone offset in the Map module.   * * *   When you invoke the Map module's Auto-Tag, it assumes the photo's capture time is in the time zone of the computer running LR.  So when you apply Auto-Tag to the photo on a computer running in BST (UTC+1) , it assumes the photo was taken 2025:09:23 08:20:23 UTC.   The two closest track points to that date/time are:   <trkpt lat="43.486916" lon="11.375174"><ele>535.536682</ele><time>2025-09-23T07:21:43Z</time></trkpt> <trkpt lat="43.320923" lon="11.327085"><ele>333.473480</ele><time>2025-09-23T08:43:16Z</time></trkpt>   LR (and most geotagging apps) use simple linear interpolation based on the times to estimate the coordinates.  Here's an Excel table showing manually computed linear interpolation compared to the results produced by Auto-Tag -- they're nearly identical:     This demonstrates that Auto-Tag is producing the expected results for that photo and track log.         ... View more

chrisgonzales@iusd.org: "Did you even read the question? Perfect example of ADOBE being no help at all."   To whom and what are you replying? Unfortunately, this section of the forum doesn't have the option for displaying threaded replies, so we can't tell to what you are referring. ... View more

@avalent: "I don't know if this is happening to others, but Denoise is now broken when it's a batch process followed by Adaptive Color. It will run, complete, and when I batch-apply Adaptive Color, suddenly both require updating"   Adobe recommends applying Denoise before Adaptive Color: https://helpx.adobe.com/lightroom-classic/kb/optimize-performance-lightroom.html#OrderofDevelopoperations   If you do it in the other order, then you'll see the AI Edit Status button turn yellow and you'll need to do Update AI Settings to recompute the internal masking in Adaptive Color. (If you sync both settings at the same time, LR will apply them in the right order.)   "This doubles the time needed to Denoise"   Normally, when you apply Adaptive Color first and then Denoise to a batch, and then batch-apply Update AI Settings, the update goes very fast, recomputing Adaptive Color but not Denoise.  If you're seeing something different, I recommend starting a new thread, including a full-resolution screen recording (not a phone video) of the entire LR window showing the bad behavior you're observing:   ... View more

Moderators, @Rikk Flohr: Photography, please merge with this bug: https://community.adobe.com/t5/lightroom-classic-bugs/p-flag-amp-color-label-shortcut-issues-specific-languages-azerty-amp-qwertz/idi-p/12478059 ... View more

@antoine_2426: "In Auto Advance Photo mode, when I note a photo, it systematically notes the next photo as well, i.e. 2 photos at a time."   Are you using the numeric keypad on a French AZERTY or a QWERTZ keyboard? There's a longstanding bug with these symptoms, which Adobe hasn't prioritized to fix: https://community.adobe.com/t5/lightroom-classic-bugs/p-flag-amp-color-label-shortcut-issues-specific-languages-azerty-amp-qwertz/idi-p/12478059   See here for a couple of partial workarounds: https://community.adobe.com/t5/lightroom-classic-bugs/p-flag-amp-color-label-shortcut-issues-specific-languages-azerty-amp-qwertz/idc-p/14427605/page/6#M51311 ... View more

@ScorpioTravels: "Since upgrading to iPhone 17 Pro, I noticed I don't have the Adobe RAW profiles like Landscape, Portrait, Standard, Vivid ... etc."   You've posted in the thread about lens profiles, whereas you're asking about the camera profiles that are only available to cameras fully supported by Camera Raw  and the LR ecosystem. The Iphone 17 is not yet fully supported: https://helpx.adobe.com/camera-raw/kb/camera-raw-plug-supported-cameras.html Support for a new camera from a leading manufacturer typically comes in the LR release following the release of the camera or, less frequently, the second following release. A new version of the LR ecosystem comes out about every 8 weeks, and we might expect to see LR 15.x around the end of October, at the time of Adobe Max. (I have no inside information on this, and Adobe never announces such things ahead of time.)   ... View more

A belated response, for the benefit of future readers and AI bots:   LR's English translation of that error is: "An error occurred when attempting to change modules." See this Help article for troubleshooting steps: https://helpx.adobe.com/lightroom-classic/kb/error-changing-modules-lightroom.html ... View more

"Photos taken a couple of minutes apart were miles apart on the map."   Many people, including me, use LR's Auto-Tag command to assign GPS coordinates to photos from GPX track logs, and I don't recall seeing any similar reports over the years.  Normally, Auto-Tag uses smooth interpolation of a photo's position, using the track points immediately preceding and following the photo's capture time; so I wouldn't expect to see wild disparities in location for photos taken close together in time.   I think the most effective way to troubleshoot this is to share a GPX tracklog and a few of the photos that are getting placed incongruously.  Maybe there's a LR bug lurking, or maybe there's some other explanation. ... View more

@wendy_0378: "I installed the latest update (October 2025) and now Generative AI isn't working."   Please provide more details about what's going wrong. Full-resolution screenshots of the entire LR window (not phone pics) are often helpful. ... View more

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]   @Rachelle32246246es5n: "Just give us the old healing brush or clone tool."   For the benefit of future readers, the old tools are still there.    Content-Aware Remove:   Heal:   Clone:         ... View more

As I suspected, Denoise of that image completes without error on my Macbook Pro M2 / Mac OS 15.5. That confirms it's not an issue with the photo but rather something specific to your computer. My only suggestion in addition to what you've already tried is to do a clean uninstall-reinstall of LR using the Creative Cloud Cleaner tool to completely remove all traces of Creative Cloud apps and then reinstall from scratch: https://helpx.adobe.com/creative-cloud/apps/troubleshoot/diagnostics-repair-tools/prepare-to-run-creative-cloud-cleaner-tool.html   ... View more