Sync 13.3 sync issues DIY resolution (from Adobe)

[atolkachev]

Lightroom Version Number

13.3

Operating System

1. macOS 14 Sonoma

After reporting my sync issues ("Uploading 1,170 images" stuck at the same number for a week, no errors, no progress) to Adobe, being asked to send two log files and waiting for a week, I had an interesting and on the whole productive session with, I assume, a level 2 support specialist Mohammad. He mentioned he was a supervisor, but there are people above him.

He acknowledged the issue and said they are working on a fix. He said not very many users are affected. He generated the sync diagnostic report (about 3 minutes and 2.2 Gb). He opened the report (lrsync_log.html) in Chrome and went to the Binary Uploader session.

He noted a file name and located it in LrC. He made a random edit. After a short time, the count of "Syncing ..." went down by one.

Basically, he (or rather, I, since I insisted on letting him go after I figured out his approach -- he called it "workflow" was stuck doing this for 1,169 more files -- or waiting for the fixed version of LrC.

We noted in the report that a lot of files from the same folder shoot were listed. Fortunately, my workflow involves renaming the files in Photo Mechanic prior to ingestion into LrC, so files from the same shoot stand out. We found 600+ files in the shoot gallery; roughly 100 of them (eyeball estimate) figured in the sync report. We made a negligible edit (Blacks +1) on one photo and synced it to all 600+ files in the folder. We then watched the count of the "Syncing ..." first go up by so many photos then quickly come down to about 100 less than the "stuck" number. The "workflow" was clearly working.

Curiously, once we nudged the count by editing a few hundred files, the number of "Syncing ... photos" kept jumping back and forth, going up, going down. A few times it bounced back and forth by the same number: Syncing 711 ... Syncing 721 ... Syncing 711 ... Syncing 721 before thankfully settling at the lower number. Mohammad advised me not to pay attention.

As of this writing, I am at "Syncing 248 photos", an improvement over "Syncing 1,170 photos" from when Mohammad started on this project. I have been rerunning and eyeballing the report and finding other large chunks of files. I would "+1" blacks on 1000 files to clear another 100 or so files from the report. I now do the find (Cmd-F) in the report page on the part of the file name before the numbers to see which shoots are represented in large numbers. I admit that when I found a shoot where 14 files were affected, but 1000+ were in the folder, I opted to find and fix each of the 14 files by hand. I imagine I will have to do more and more precision edits as I go.

Hope this helps someone who has not yet gotten a call from Mohammad or his colleagues. Until the fix is ready, this is all you or anyone can do.

 

[atolkachev]

Mohammad made an interesting aside remark that the issue such as mine is often (usually? always?) caused by users using Rebuild All Sync Data (hence the recent change where we are admonished to only use it when told to by Adobe support) and by shutting down LrC while sync is in progress.

I admit that in the past I had no problem shutting down LrC while sync was in progress because 1)sync would take FOREVER and 2)LrC told us it was okay. In fact, shutting down and restarting LrC would often get sync in gear. But after being told this by an L2+ specialist, I am reluctant to shut down LrC even to install 13.3.1 until sync is done. Now, if 13.3.2 comes out with the sync fix, I am definitely installing it, because the last 248 files may take a while to nudge one by one.

 

[atolkachev]

I think there is a slight wrinkle to this workaround, which I will be discussing with Mohammad via email.

It seems that only files from the sync report with binaryType: proxy (whatever that means) are positively affected by the nudging of an attribute in Develop.

There are several other binaryType values in the report: binaryType: aux and binaryType: xmp_develop. And I think these also go with various values of the isReadyToUpload. Proxy is 0, the other two are 3 and 2 respectively. This probably means something to someone and maybe even can be used to our advantage to improve the workaround.

I am finding that several of the files from the shoot (folder) that I have previously "fixed" by editing and syncing an attribute are still on the report with isReadyToUpload set to 2 or 3. I feel that only files that had isReadyToUpload = 0 and binaryType = proxy are successfully dropping off the report.

Any thoughts or observations?

 

[Victoria Bampton]

Hi atolkachev, thanks for sharing. If all of the stuck syncs in your catalog are fixed that way, that's great. As you've discovered, that only clears some of them, as not all of the stuck syncs are listed in the html log. Some require engineers to look into the databases themselves. Support are supposed to be passing the logs back to the engineers, but many are not doing so at this point.

Since many of the stuck syncs are account-specific, they're unlikely to be fixed by a general software update, so for anyone who still has stuck syncs, the engineers have said that they're happy for us to collect logs and pass them on to them. To do so:

1. Go to https://www.lightroomqueen.com/troubleshoot-sync-with-classic/ and confirm you've done troubleshooting steps 1 and 2, so both All Sync Errors in Classic and Sync Issues on the Web are empty.

2. Create the diagnostic log in step 3 on the troubleshooting steps.

3. Send it to us at [email protected], and make sure you include your Adobe ID and a description of what's going wrong. The log is a big zip file, so you'll need to use something like WeTransfer (free up to 2GB without an account or 3GB with a free account) or SendBig (free for bigger still) to get it to us. There's instructions on how to use WeTransfer here: https://www.lightroomqueen.com/member-help/send-diagnostic-log/

4. We'll pass it on to the engineers, along with your email address, so they can contact you with a solution to fix the leftover ones.

 

[atolkachev]

Thank you, Victoria, I am likely to take you up on this offer. I think the workaround has run its course. While 173 stuck files is an improvement on 1,170, it's not zero. I see in the report that almost all stuck files are listed multiple times with binaryType = aux, xmp_develop and proxy or a combination of those. I am sure this will make sense to the engineers and will either help them complete their fix or come up with the next level workaround.