Saturday, March 28, 2020

"Why Do My Old Keywords Keep Reappearing on Photos in Adobe Bridge?"

Adobe Bridge can be infuriatingly quirky if you've ever applied hierarchical keywords to your photos in either Bridge or Lightroom. What are hierarchical keywords? Those are the keywords organized in levels, like "Places > Washington State > Seattle" or "Events > Anniversaries > 50th." Besides being associated with each other, they can even be applied together automatically.

Using hierarchical keywords is a safer practice in Lightroom, because the keywords and hierarchy for each file are kept primarily in a central database or "catalog" and can be instantly modified there for your entire photo collection. But Bridge has no such database -- nothing at all but a simple list of keywords to show in the Keyword panel. The keywords and hierarchy for each photo can only be written directly into the individual photo file or its associated XMP file. And if you modify your hierarchy in the Keyword panel, or discard it entirely, the original scheme is still written into the files you've applied it to.

What's more, whenever Bridge reindexes that file for a search, it may use that old hierarchical scheme to replace keywords it concludes are missing -- even if you've since changed or deleted those keywords. In Adobe's eyes, that's a feature, not a bug. They're helping you out. Thanks, Adobe!

To put a stop to this paternalism, the first thing you must do is TURN OFF hierarchical keyword functions. In the Keywords panel of Bridge Preferences, turn off ALL options: "Automatically Apply Parent Keywords," "Write Hierarchical Keywords," and "Read Hierarchical Keywords." You can still create a keyword hierarchy in the Keyword panel and apply parent keywords manually, you just can't let Bridge apply them automatically.

If you are working with Lightroom as well, do NOT use it for keywording. If you do, depending on your settings, you'll either have inconsistent keywording between Lightroom and Bridge, or you'll have Lightroom writing its hierarchical keywords to your photo files, where Bridge will read them.

These steps will stop Adobe from making your problem even worse, but you still need to clean up the mess already made. To do that, you have to understand where those pesky keywords are stored.

With Adobe, that's in three separate keyword fields in a photo's XMP -- the collection of data fields inserted into the photo file itself or into an associated XMP file. (In Bridge or Lightroom, the XMP file is normally hidden, but it's plainly visible in the Mac's Finder.) The fields are officially called:

dc:subject -- This is part of the IPTC Core metadata. It's your primary keyword field, an industry standard, and any modern keywording program will read and write it. You want all your keywords and ONLY your keywords to appear in this field.

iptc:keywords -- This is the keyword field found in the older, "legacy" IPTC data set. You don't really need it except for compatibility with older apps. For safety, Bridge synchronizes this field with dc:subject.

lr:hierarchicalsubject -- This is where Bridge stores info on hierarchical keywords -- and where Lightroom does too, if it writes that data to individual files. So, this is where Bridge may find "missing" keywords it then decides need restoring.

The Metadata panel of Bridge displays and lets you directly edit the keyword fields of both IPTC Core and legacy IPTC -- assuming that viewing of these fields is turned on in the Metadata panel of Bridge Preferences. Bridge makes sure that changes in one field are reflected in the other. You can also add or remove keywords from both these fields together in the Keyword panel.

The story is different with the third field, lr:hierarchicalsubject. You cannot view the contents of this field in any Adobe app, and you cannot directly edit it. And that's one reason Bridge can drive you nuts. Even if you entirely stop working with hierarchical keywords, the old ones are still built into the XMP for individual photos, where Bridge still reads them. They can then reappear in the visible keyword fields, seemingly out of nowhere.

This third field is proprietary to Adobe -- so while Adobe provides no help with it, neither does any other app. But there is one tool that can help: Phil Harvey's ExifTool (www.exiftool.org). It's a Perl library that's called from Terminal's command line, and you can use it to remove all data from this field.

After installing ExifTool, you would type or paste the following command into Terminal, followed by the path of the file or folder you want to process, and then press Return or Enter.

exiftool -overwrite_original -xmp-lr:hierarchicalsubject= -r

For instance, the command with the path to my photos folder looks like this:

exiftool -overwrite_original -xmp-lr:hierarchicalsubject= -r /Volumes/Docs/Works/Photos/

If you're not sure how to write your desired path, you can just type or paste the first part and then drag the folder or file into Terminal.

Note that, if you have a lot of photos, ExifTool's processing takes a LONG time. At the end, Terminal will show a summary of results, but your only feedback meanwhile will be when ExifTool issues an error message or warning. Aside from that, the only way to make sure ExifTool is running is in Activity Monitor.

Also note that ExifTool will SKIP a file if it finds any error in the metadata. (I had this problem with close to 300 files that had started life as Nikon NEFs, been edited in Capture NX 2, and later been converted to DNG -- a sequence that seems to consistently produce the ExifTool error message "Bad MakerNotes offset for NEFBitDepth.") You can tell ExifTool to process the file anyway by adding "-m" to the command -- but then you risk even worse corruption.

Once you've removed the hierarchical data, it's worth making sure that Bridge can't remember what you've deleted. You do that by going to the Cache Management panel of Bridge Preferences and hitting "Purge All Local Cache Files." Just be aware this also means you'll lose all thumbnails Bridge has previously built for your files!

You should now be able to search your photos and remove the keywords you don't want. But notice I said "should." In my own case, I STILL had unwanted keywords reappearing.

The problem, as I came to understand it, is that the Bridge Metadata and Keyword panels, because of corrupted metadata or whatever reason, sometimes fail to write your edits to the file -- AND BRIDGE DOESN'T NOTIFY YOU. The panels show the changes, and they're probably in Bridge's cache, but they're not in the photo XMP. The next time you reindex the photo -- say, on running a keyword search the very next time you open Bridge -- all the old keyword data returns to Bridge's panels.

Luckily, I discovered a solution to this. With any problem file, IGNORE Bridge's Metadata and Keyword panels. Instead, make your changes in the File Info dialog, accessed from the File menu or the contextual menu. This command not only writes your data reliably to both of the visible keyword fields in the photo's XMP, but it also fixes whatever problem was present, so that you then CAN safely use the Metadata and Keyword panels for your changes.

Actually, I need to qualify that. This fix works if you're using a LATER version of Bridge. Applying this method in Bridge 2018 fixed only SOME of my problem files. The same method in Bridge 2020 fixed ALL of them.

At least, I THINK they're fixed. That's how it looks so far.  ;)

Thursday, March 26, 2020

"Why Are My Adobe Bridge Keyword Searches and Smart Collections So Slow?"

Because that's what you've chosen.

When you start a keyword search or create a Smart Collection, you're given a default option to "Include All Non-Indexed Files." And right next to that appears the warning "(may be slow)."

Folks, they're not kidding. When you leave this checked on a first search after starting Bridge -- or first view a Smart Collection created with this option -- the app goes through EVERY target file and folder and reindexes it, just in case any files were changed or added since the app was last open. This takes a LONG time. After that, Bridge relies on those cached indexes it just made, but it STILL scans all target folders to make sure no files have been added. This takes much less time, but it's still far from instant.

Now, let's look at what happens if you uncheck this option. Boom, you're done. Bridge relies only on its cached indexes, and really, if you blink, you'll miss it. The downside, though, is that you really do need to make sure you haven't changed or added any files outside Bridge. If you have, Bridge won't know about it, and the keyword search or Smart Collection can miss some files or give false positives. (To fix this, you'll need to trigger a reindex by running a search that DOES include all non-indexed files.)

The first lesson here is, if you want to run quick and ACCURATE searches in Bridge, you'll need to make all your file changes and additions in Bridge itself -- oh, and don't let your cache run out of disk space. (You can adjust that in Preferences.)

The second lesson is, don't blame the app if you haven't even looked at the options it gives you!

BONUS TIP -- Full-size previews not looking too great in recent Bridge versions? Go to the Advanced panel of Bridge Preferences and turn on "Use Software Rendering." Bridge's new hardware acceleration may omit applying sharpening and noise reduction to those previews.

Sunday, July 7, 2019

"Should I Update My Old Mac from High Sierra to Mojave?"

If you rely on old hardware or on old software you can't update, I suggest you leave Mojave alone. You're likely to run into a number of more or less serious incompatibilities without gaining much to compensate. In my own case, I had enough problems that I wound up downgrading from Mojave to High Sierra -- the first time I've ever had to revert to an earlier version of the operating system.

Here are a few specific reasons you might want to stick to High Sierra.

1. Sketchy support for older Macs. With my 2010 Mac Pro 5,1, I had to temporarily disconnect all internal drives except the boot drive before I could install or reinstall Mojave. Otherwise, the installer would stop partway through with an error message.

Also, Mojave required a firmware update that caused some sort of error with the saving of startup disk info. TinkerTool System identifies it as a problem with NVRAM, and though the Mac starts up on the correct disk, shutdown times can be unusually slow when switching startup disks. (This may actually have come with the firmware update in a later version of High Sierra, but since I did one right after the other, I can't be sure which update caused the problem.)

Note that this problem persists even if you go back to High Sierra. And as far as I can tell, there's no way to revert the firmware.

2. Sketchy support for older graphics cards. My AMD Radeon 7950 is on the list of graphics cards that Mojave officially supports, but its bootup screen showed weird purple streaks, and partway through startup, I got a few seconds of complete blackout -- neither of which the card gives me with High Sierra. It made me wonder what other incompatilities were lurking.

3. Sketchy support for older printers. While trying to figure out why BBEdit was suddenly printing with uneven font weight, I discovered that my HP Laserjet P2055 was officially NOT supported in Mojave. Driver support ended with High Sierra, apparently because Mojave's changes in printing were too much trouble to update for. Seriously, have you ever heard of a functioning LaserJet that went obsolete due to lack of a driver update?

4. Sketchy support for older software. For example, Adobe Photoshop's Save for Web no longer saved its current settings between Photoshop sessions, making you reenter them each time. This was fixed in a Photoshop CC 2019 update -- eight months after the issue was reported! -- but it will NEVER be fixed in earlier versions, including Photoshop CS6, like my wife is using.

The deal breaker for me, though, was discovering that Microsoft Word 2011 could no longer properly handle some GIFs when in .doc files or while saving to HTML. While that might sound like a minor problem, and while I could have resolved it by updating Word, I rely on that particular file format and Word version for producing Kindle books -- and since the app was completely rewritten in later versions, adjusting my workflow would have been a huge effort. At this point, I decided it was simplest to go back to High Sierra.

5. Difficulty in reverting. Luckily, all I had to do to revert my Mac Pro was switch to the partition where I still had High Sierra installed and then move over my recent email and redownload some app updates. It took most of a day, but it was manageable. But for my MacBook and my wife's, it was a different story.

It turns out there are just enough changes in the file systems between High Sierra and Mojave to cause trouble for High Sierra. Just replacing my Mojave system files with High Sierra files from a backup didn't work well enough, because the disk still had what High Sierra's Disk Utility believed were "invalid internal_flags."

Disk Utility's notices were warnings only, and I can't be sure those errors would ever have actually caused trouble -- but I didn't want to wait to find out. To get rid of them, I wound up erasing the Macbook drives entirely and then restoring ALL files. And that's pretty nervewracking. (Especially when the MacBooks then couldn't locate a bootable drive, and I had to use Startup Disk on the Recovery partition to fix it.)

Apple, I feel, did a real disservice by not putting off abandoning OpenCL graphics till the end of official support for 32-bit software and the old Mac Pro towers. The result is that you might think you can safely upgrade when you really can't. And if I'd known how tricky it could be to go back to High Sierra, I would never have tried.

For me, High Sierra may well be the end of the road. I updated to Mojave mainly because I was worried about eventually having to buy a new Mac with that MacOS version. But after checking on eBay, I have a new solution. I'll just buy another 2010 Mac Pro!

Update, Aug. 5, 2019 -- Some time after reverting to High Sierra, I discovered I had also lost access to the Recovery volume from the High Sierra partition on my Mac Pro, apparently because it had Mojave software. The solution was to reinstall High Sierra over the existing installation. This replaced the Recovery software with High Sierra's version.

Tuesday, June 25, 2019

"How Do I Stop Adobe Background Processes from Launching at Startup on My Mac?"

Adobe's Creative Cloud app is like a virus, and a poorly programmed one at that. Though the app needs a number of background processes when it's running, they don't need to launch before then, and especially not when you start your Mac. But how do you stop them? And beyond that, how do you keep Adobe from restoring them?

Most of these processes -- all of which you can identify in the Mac's Activity Monitor by the Adobe logo -- are launched at startup by files known as launchagents and launchdaemons. There are three main locations where Adobe installs these:

Library/LaunchAgents/
Library/LaunchDaemons/
Users/[Your Username]/Library/LaunchAgents/

(If you don't know how to reach the hidden Library directory, pull down the Go menu in Finder while you're pressing the Option key.)

The names of the files that launch Adobe processes all start with "com.adobe", and NONE of these files are essential. Most of the advice you'll find on this topic simply tells you to trash them. That works well enough, but only until the next Creative Cloud update, when Adobe will reinstall them. But here's how to do away with them for good:

1. Copy the filename, making sure you include the "plist" extension.

2. Move the file to the trash, authorizing if necessary.

3. Create a new folder in the same directory.

4. Paste in the old filename as the new folder name.

Why does this work? The Mac Finder doesn't normally allow a file to overwrite a folder of the same name -- so the next time Adobe tries to install those files, it will fail. Still, you'll want to keep on eye on these three locations, for when Adobe installs a file with a new name.

With its launch files missing, Adobe will just have to wait till you launch the Creative Cloud app before it can run its processes. But keep in mind that, once you run the app, quitting it won't stop those processes too. You'll have to restart your Mac for that.

After taking care of launchagents and launchdaemons, there's one more process to stop. Go to the Extensions panel of System Preferences and click on Finder Extensions in the sidebar. Uncheck the box next to Core Sync Helper, and that's it -- though here too, you may have to repeat this action after installing a Creative Cloud update.

Update, June 26, 2019 -- OK, I found one reason you should leave Adobe's background processes intact. I encountered a bug in Photoshop's Save for Web, which wasn't saving its current settings under Mojave. After realizing it had compromised several hours of my work, and after failing to figure out a fix on my own, I went online to research it.

It turns out the bug was reported to Adobe eight months earlier, and it had taken them this long to fix it, but they'd done it -- in an update that was released about five days earlier. But because I had all the background processes shut down, I wasn't notified.

Something to weigh.

"Why Is My Mac Having Wi-Fi Problems After Updating to Mojave?"

A number of people have reported having Wi-Fi problems after updating to Mojave, and I did myself, with a disturbing lost connection in the middle of a big download. That's something I'm not used to.

What I discovered was that Mojave had re-ordered my Preferred Networks. What really was causing the trouble was that I was now connected to a 2.4GHz network instead of my usual 5GHz. A 2.4 GHz network will often be subject to more interference than 5GHz, so the connection is more likely to fail. And sure enough, when I switched networks, the connection was fine.

If you're having trouble, the first thing to do is check the network you're connected to and switch it manually if it's wrong. You can do this with the Wi-Fi pull-down menu on the menubar (if you have it there) or on the Network panel of System Preferences. It's common for a wireless router to offer both 2.4GHz and 5GHz connections, and you want to make sure you're on the one that has worked best for you in the past.

After that, on the System Preferences Network panel, click on Advanced, and you'll see a list of your preferred networks. Move the one you prefer to the top if it's not there already, then click OK. Then there's one more step: At lower right in the Network dialog, click on Apply. If you don't, your changes will be lost.

Hopefully, that will do it!

Friday, April 12, 2019

"Why Does the Mojave Installer Fail on my Old Mac Pro with the Message 'The Installer Resources Were Not Found'?"

When it comes to new versions of MacOS, I'm not exactly an early adopter. In fact, I usually wait about nine months before daring to move over. That's usually how long it takes for all the bugs to get worked out of the MacOS version and all the software that's going to be updated for it.

For Mojave, though, I wanted at least a sneak peak, because I wanted to see if my 2010 Mac Pro and aging software could weather the transition at all, or whether I was stuck at High Sierra. So, I installed Mojave on a test partition when it first came out of beta, and after playing with it enough to allay my fears, I forgot about it.

Until recently, when I tried to update it for more testing. Then I found I couldn't. The installer kept failing with the message, "MacOS could not be installed on your computer. The installer resources were not found." So, one of the Mojave updates beween 10.14 and 10.14.4 had a bug in the installer, because someone at Apple wasn't paying attention to old Mac Pros.

I still don't know the exact problem, but I did manage to work around it, with the help of a clue buried in the forum at www.tonymacx86.com. It really wasn't that hard: I just slid out all the drives in my Mac Pro except the one with my startup volume on it. Then the installer was able to find its resources just fine. (It may have helped that my startup volume was on an Apple SSD that was sold for my Mac Pro.)

And here's a bonus solution that I would have tried next: Copy your startup volume to a MacBook, update it there, and copy it back over. Again, the problem is only with Apple's installer, not with Mojave. As long as you have a graphics card with Metal (as I do), Mojave seems to run just fine on a 2010 Mac Pro.

Tuesday, March 26, 2019

"Why Won't My Mac Pro Restart After the Latest Software Update?"

I have a 2010 Mac Pro 5,1, and after downloading a High Sierra security update from the App Store last night, trying to restart landed me on a black screen with a cursor, and that's all. I could power down by holding down the power button and then boot back up, but my next attempts to restart failed the same way.

Checking online, I saw that the update included new EFI firmware, and that gave me a clue how to fix it. My boot volume was on a Sandisk SSD, but I had another system volume on an original Apple SSD meant for this Mac Pro. For past firmware updates to this machine, I'd had to boot into the Apple SSD volume to get the firmware installed. So, I tried that again, and sure enough, I was able to download the update and restart, with the update proceeding just fine.

Unfortunately, this boot volume didn't have my latest files. So, back I went to my Sandisk SSD volume, used SuperDuper to copy all files to the Apple SSD volume, then booted back into that and updated it AGAIN. (That took two separate trips to the App Store -- it didn't all update at once.) Once THAT volume was square, I copied everything BACK to the Sandisk SSD volume -- and then that volume too worked perfectly.

To recap, the update apparently failed when attempting to install firmware for my Mac Pro because it disliked the Sandisk SSD and/or the adapter I bought to install it. I had to update on the Apple SSD boot volume, then copy the updated system to the Sandisk SSD. That process also got rid of the update installer on the Sandisk so that the installer wouldn't keep causing failure at restart.

A whole evening down the tubes.

Since my problems with firmware updates from the Sandisk SSD have gotten worse, not better, I've returned to using the Apple SSD volume as my main boot volume, despite it being specced as considerably slower. I don't know why Apple can't handle firmware updates on a third-party SSD plus adapter, but their continuing botched updates with the old Mac Pro make me wonder how long I can even keep this machine running. If that original Apple SSD goes out on me, another buggy update could be even more trouble than this one.

Maybe I should buy another Apple SSD as a backup? Or maybe just get a new Mac before they stop running 32-bit software?

UPDATE, April 2, 2019 -- Apple apparently screwed up the original High Sierra update, because they've reissued it with "restored" security fixes a few days later, giving me the chance for further experiment. It looks like the trouble Apple was having on my Sandisk was in unmounting a system volume that shared an APFS partition with other volumes. Trying the update on a system volume that was alone in its partition on the Sandisk, the installer had no trouble at all.

Whether I would have had trouble with a multivolume APFS partition on the Apple SSD, I can't say. In general, though, I'm finding it safest and less troublesome to stick to one volume per APFS partition on my Mac Pro.

But if you do have multiple volumes in a partition and run into such an installer hangup, you might avoid it by using Disk Utility to unmount the other volumes before restarting. Worth a try, anyway.

So, here's my formula for the most trouble-free setup on an old Mac Pro: Stick to one volume per partition, and keep your main startup volume on an official Apple drive.

UPDATE, Sept. 1, 2019 -- The latest High Sierra security update, 2019-004, has restricted configuration safety even more. It could not find the installer resources on my Apple SSD with two MacOS partitions on it -- one with High Sierra, the other with Mojave. I had to delete the Mojave partition to get the update to complete.

UPDATE, Nov. 15, 2020 -- One more High Sierra security update, 2020-006, and this one again failed to install, bricking my Mac Pro. I have given up on all Apple security updates. At this point, the biggest security threat to my Mac Pro is Apple itself.