The Robservatory

Robservations on everything…

 

OS X Rants

Create ‘and/or’ Smart Playlists in Photos

I’ve recently—begrudgingly, forcibly—migrated from iPhoto to Photos. My iPhone 8 Plus was the main impetus, as Photos supports its new movie and image formats, as well as providing some additional editing features that I can’t get in iPhoto. But in my limited time with the new app, my general conclusion is that Photos is not designed for someone who likes to actively manage their photo collection.

I may have more to say about this in a future post, but for now, consider this style of Smart Playlist that I used a lot in iPhoto…

This structure effectively creates an “and and or” logic, where you can have all conditions must be true at the top, yet have an “or” on the keyword: This playlist finds media that have the keyword Midnight or Moonlight (our cats), and are videos.

You simply cannot build this structure in Photos, because the Keyword field is a tokenized pop-up; you can only select one value. If I list the keywords as separate criteria, I wind up with a Smart Playlist that only finds videos with both Moonlight and Midnight. That’s not what I want.

This structure is useful whenever you have multiple individual things—kids, lets say—and you want a smart playlist that will find any of your children and any other criteria, like year or camera or whatever.

My first thought at a workaround was to create a Smart Playlist called The Cats, which simply had the two Keywords as “or” criteria. I’d then create a second Smart Playlist that had one criteria set to “Playlist is The Cats” and the other set to find only videos. But Photos won’t let you use a Smart Playlist as a criteria (neither will iPhoto, for that matter).

After some fiddling, I came up with an ugly but functional solution: I have to use an extra keyword. Now, any time I add photos of either cat, I have to set two keywords: One with the cat’s name, and the other is The Cats. With two keywords on every cat photo, I can use this Smart Playlist to make my “video of either or both cats” Smart Playlist:

I’ll have to do the same for our children; each picture of Erica or Kylie will also get a The Kids keyword. It really shouldn’t be this hard; Smart Playlists should work as do Finder searches…

Perhaps in Photos 4…or 5…or 6. Sigh.

Apple says don’t use Time Machine if you take lots of photos

I know that’s a shocking headline, but that certainly seems to what they’re saying for a certain group of users (red emphasis added):

By default, your System Photo Library is stored in the Pictures folder on your Mac, but you can move it to another location on your Mac or store it on an external storage device.

WARNING: If a Photos library is located on an external drive, don’t back up the drive using Time Machine. The permissions for your Photos library may conflict with those for the Time Machine backup

That’s taken from the System Photo Library overview, part of Photos’ help. In a nutshell, Apple recommends that if you’ve moved the System Photo Library to an external drive—as nearly anyone who takes lots of pictures will have done, given space-limited solid-state internal drives—you do not use Time Machine on that drive. Not just “don’t back up the Photos Library folder with Time Machine,” but “don’t back up the entire drive with Time Machine.” Yikes!

Think about that for a bit…this affects anyone with limited internal storage space who has their photos stored on an external drive. And in today’s Mac world, that could be a lot of people—while you can configre some machines with up to 2TB of solid state storage (and iMacs with bigger Fusion drive), doing so is wildly expensive. So there are potentially a lot of Mac users with small internal drives who may be affected by this. Yikes again!

Apple’s writeup leaves me with a couple of critical questions…

  • What if I exclude the iPhoto Library folder from Time Machine—is that sufficient to prevent the permissions issues, such that I can use Time Machine for the rest of the drive?
  • How, exactly, am I supposed to back up my photos, if I can’t use Time Machine? (See update at end for Apple’s recommended solution.) Will SuperDuper or CarbonCopyCloner also run into permissions problems? I’m using a 1TB Flickr account and their upload tool as a backup method, but I have lots of upstream bandwidth, so it’s not bad…but not everyone is lucky enough to have fiber to the door.

I know Apple’s answer to the second question is “You shouldn’t be storing photos locally, they should all be in the cloud.” But if you have a huge collection of photos and videos, and/or if you’ve got slow or limited internet, this is not a realistic option.

My library is over 40,000 photos and 1,400+ videos, requiring in excess of 500GB of storage. At that level, I’d need the 2TB iCloud plan at $10 a month…versus Google and Amazon, both of which offer unlimited photo storage space for free (though Google has caps on image and video resolution). So if I have to go to the cloud for primary photo storage, I don’t think I’ll be using Apple’s solution (even though it’s obviously the best-integrated).

Seriously, Apple, tell me how to back up the 8TB external drive I’m using to hold my photos…there must be an Apple-accepted solution, right?

Update: Ed Mechem’s comment points out Apple’s Back up thew Photos library page, which recommends simply dragging your Photos library to another drive to back it up. Thanks Ed; that appears to address the second question. I don’t know if it’s OK to copy it to the Time Machine drive, just outside the Time Machine folder, or if you’d ideally need a third drive. You’d want to use an app like CarbonCopyCloner or similar to automate this process, obviously. Manual backups aren’t usually the best solution.

Be aware of this Applescript-with-droplet bug

Another post thanks to Many Tricks‘ Peter Maurer; this particular bug bit me last night—I spent 30 minutes trying to figure out why a compiled AppleScript with a droplet wasn’t working. I never did get it, so I emailed Peter, and he pointed me to these tweets from a while back…

And yea, that was the problem: As soon as I added the +x to the compiled script, everything worked as expected. The exact syntax is:

chmod +x /path/to/compiled.app/Contents/MacOs/droplet

I’m documenting this here so that I can find it more easily the next time I save a compiled droplet AppleScript and forget about this not-so-little bug.

Fix Messages’ broken bundled AppleScripts

While playing around with Messages this morning, I noticed that it ships with a feature that, if used, throws an error. Steps to reproduce:

  1. Open Messages’ preferences.

  2. Set the Applescript handler pop-up to any of the listed scripts:

  3. Close preferences, and try to send a message to anyone.

  4. Revel in the brokenness.

I especially like the execution error: No error message…it’s that rare non-error that tosses up an error dialog!

In any event, I think it’s shameful that Apple ships the app with a feature—plainly obvious in prefs—that breaks when used. Yes, I know AppleScript is probably dying, but that doesn’t excuse shipping the app with a clearly-broken feature; if it doesn’t work, just remove it. Apparently this has been an issue since Yosemite’s release in October of 2014!

With all that said, fixing this is incredibly easy—it took me about 30 seconds of “work” to find and fix the problem. If you’d like to use the bundled AppleScripts in Messages—either as is, or in some modified form—here’s what you need to do

(more…)

A possible fix broken search in macOS Mail

Over the weekend, I wrote about my totally useless search in Mail. I got so frustrated by my inability to search in Mail that I decided it was time to for a complete rebuild. I exported all my locally-saved mail, deleted my accounts, quit Mail, trashed its prefs and data files, rebooted, then rebuild it mailbox by mailbox, account by account.

I started with my iCloud account, which I barely use for anything—it has a total of seven messages in the inbox (four of which are iTunes Store receipts), and only 121 sent messages. As a test, I searched for Linea, an excellent drawing app that I had recently purchased. No matches.

At that point, I decided to quit Mail and force Spotlight to rebuild its index overnight. In Terminal, sudo mdutilmdutil -E / will do just that (and take many hours). Today, opened Mail, and search was still dead. Argh! (I had also tried this suggested fix, but it made no difference.)

But doing some random testing today, I discovered a fix! It’s a weird fix, but it seems to work:

If I move all the messages from an inbox or local storage folder into a different local storage folder, they’ll be indexed and findable. I can then move them back into the inbox or source folder, and they remain findable.

Even more important, newly-added messages seem to be properly indexed, in both the inboxes and the local storage folders.

This doesn’t make any sense to me, as any one of my recent actions—rebuilding mailbox indexes, reimporting, and redoing the entire Spotlight index—should have been enough to force a rebuild. But for whatever reason, only manually moving the messages seems to force a rebuild.

Now pardon me while I go back to manually dragging a quarter-million email messages around…

On the uselessness of search in macOS Mail

For the last couple macOS releases, I’ve had nothing but trouble searching in Mail. Note that I didn’t write “trouble searching mail,” but rather, “trouble searching in Mail.” For example, today I needed to find an email from my business partner Peter about a hidden pref in Butler. (I was hoping this pref could help a user who was having problems with the pasteboard in a certain app.)

Based on a document on my hard drive, I knew the name of the default was Pasteboard Normalization Interval, but I couldn’t remember the syntax of the defaults write command to set its value. So I searched in Mail…

So clearly, no emails in my database contain the words I’m looking for, right? Here’s the exact same search, run in Spotlight:

Not one but two email messages match my search, and provided the needed syntax for the command.

Wait, I know what you’re thinking: “Ahh, look, it’s in quotes!” Doesn’t matter; searching Mail for "Pasteboard Normalization Interval" still results in zero matches. Searching on even one word of the phrase, like Normalization, also finds no matches.

Again, I know what you’re thinking: “Oh, I bet the Mail index is screwed up.” Nope; even after rebuilding the index on all 250,000+ messages in my database, no matches are found. (And yes, I let the index complete its rebuild, which took hours.)

I’ve heard from others that search in Mail works for them. But it’s a no go for me, and I know, for others. So something’s wrong, but I don’t know exactly what it is, nor how to fix it.

So for now, I have to rely on Spotlight to search Mail…or a third-party app, but more on that in a bit.

The Finder’s GUI tax can be very expensive

Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the “Open ‘safe’ files after downloading’ item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).

If you work with lots of compressed files, you’re probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…

[Note: Technically, this isn’t Finder, it’s Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it’s what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it’s Finder handling the expansion. For ease of reference, I’m going to say it’s Finder doing the expansion.]

Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—”it took over 12 seconds to expand 25 tiny little archives!”—when what they really have is a horrendously slow GUI interface to a super fast task.

Just how fast is the task, if the GUI doesn’t get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you’d use this command in Terminal:

gzip -d -k *.gz

If you try this, you’ll find out it’s nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:

$ time gzip -d -k *.gz

real	0m0.013s
user	0m0.002s
sys	0m0.005s

This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…

Expand 24 .gz files Finder:
12.8 seconds
Terminal:
.013 seconds
Terminal is 984.6x faster than Finder

To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That’s nuts!

(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)

So it’s not the computer that’s slow, it’s the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there’s no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.

Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.

This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it’d be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here’s one way to do just that.

Fix Messages’ image pasting by killing its engine

Kirk McElhearn explains how Messages in Yosemite has trouble sending pasted images. These problems typically only occur between people who use AIM accounts in Messages; sending pasted messages when using iMessages’ accounts seems to work fine. (I use an AIM account to keep iMessage traffic off my main Mac, and for its great screen sharing.)

Kirk’s article details the fix, which is to kill the imagent process, which is what controls Messages. He uses Activity Monitor to do so, which works fine. But I have to kill the stupid imagent many times a day, so I wrote the World’s Easiest AppleScript™ to do the work for me.

(more…)

Fun with iTunes’ new math

Unlike my previous incidents with iTunes and iOS devices, today’s report isn’t on a sync problem per se.

It’s more like a math problem which then leads to a sync problem. Here’s the tl;dr version: I have an iPad with 5GB of free space, and I cannot add a 1.8GB movie to it, as iTunes eventually tells me it needs another 526MB of space in order to do so.

During the attempted sync of this movie, iTunes displays some horridly bad math skills; just watch the video to see.


Here’s the video at its full size (1164×1056).

I have no idea how to resolve this, short of restoring the iPad, which I’d rather not do. (I’ve already unsynced and resynced everything, in an attempt to straighten out the math, but to no avail.)

Yosemite’s constant clattering clutters Console

For those who aren’t familiar, Console (found in Applications > Utilities) is an application that shows you what’s happening beneath the lovely skin of OS X. Open the application, and you’ll see a combination of status and error messages from any number of sources.

If you’ve never looked at Console before, you might be surprised by just how much stuff gets written there. But with the release of Yosemite, things have really taken a turn for the worse—the amount of stuff written to Console is greater than I recall for prior OS X releases.

As a test, I set up a new Yosemite virtual machine, installed ScreenFlow (and nothing else), then launched and interacted with a number of Apple’s apps for two minutes while recording the screen. The results are quite sobering; here’s what two minutes of Console logging looks like, reduced to a 10-second movie:

As you can see, there are a lot of Console entries in just two minutes.

(more…)

The Robservatory © 2017 Built from the Frontier theme