Mac Bluetooth keyboard sluggish - and/or repeats?

Symptoms

• Press a key – no response.
• Or a several-second time lag, before any output.
• Press a key (even briefly / lightly) and several characters are output.

When observed

• After some time (hours to days).
• Usually, when the screen is locked or asleep
• Which makes entering the password, functionally impossible.

Equipment

• MacBook Air (M1, 2020)
• Apple Magic Keyboard (on Bluetooth)
• macOS Big Sur (V11.4 (20F71))

Workaround

1. Hold Shift and Option, then click the Bluetooth icon in the menubar.
• Yes; challenging when having KB trouble. 😕
• Though at least possible, since these are keys meant to be held down.
• If even this doesn't work, hopefully you have a wired KB handy…
2. Select "Reset the Bluetooth module".
• Hmm; maybe this is possible to trigger with no KB use…
3. There is no step three 😏

Shoutout to the good folks at OSXDaily.

I just dismissed the screensaver - why is every keypress ignored?

You just authenticated to your Mac, and the screensaver cleared, to put you right back to where you were - almost.

This is why every keypress is ignored - aside from beeping at you.

Look more closely… Why are the window controls grayed out, as if it's not the active window?

Yeah; it's not exactly right back where you left off - the keyboard focus has not returned to your window; apparently, a side effect of the screensaver. 

Solution: Click where you want the focus (your document, terminal window, whatever), and off you go.

Note: This also affects at least some global key equivalents (I recently whipped up something to really Skip a track in iTunes) - and in such cases the solution is the same: Click somewhere, and they'll work.

Weird.

Music (was iTunes) and Skipped vs Played - ish

Turns out, Apple's macOS Music app, uses some arcane rules to determine if and when a track is logged as a Skip, or Played.

Which doesn't much matter - unless you want to use that info in a Smart Playlist. 😕

I want to listen to something different, so I use that metadata, to filter out tracks either recently listened to, or recently skipped - which shakes things up nicely.

For awhile now, it's been nagging at me, that I seemed to be hearing tracks I should't - a bit of research led to the link above. I frequently hit the FF button within the first few seconds, so those don't count as Skips. 😕

I wrote a quick AppleScript to use, instead of the default FF button, and force a Skip (by first moving playback to the 6s mark); I use it on a Quicksilver Trigger (see p. 34 of the Quicksilver manual) - though you can use this code however you like:

tell application "Music"

if player state is playing then

set player position to 6

next track

end if

end tell

I'm no expert at Quicksilver Triggers, however here's how I set it up:

• Open Quicksilver and navigate to Triggers (icon in top menu).
• Press dot (period), in the top pane, to be able to paste text.
• Paste the code above (newlines and all).
• The 2nd pane may already be set to the proper kind of code execution: "Run as AppleScript".
• If not, set that.
• If it's not available, you may have to enable that Action.
• Click "Save".
• Click into the "Trigger" column (right), to assign a hotkey.

iCloud Drive: some files refuse to upload

I recently moved a large group of files (many directories) to iCloud Drive - so they'd be available on my other devices - and watched as they all uploaded...

Then did some testing to confirm - only to find that many files never did upload. (I tested over the course of _weeks_; this was not an issue of bandwidth.)

I compared (using diff) the state of the Mac on which the files were first moved into iCloud, versus the files on another Mac which was freshly set up with iCloud, so got them only via iCloud sync. (I also spot-checked, using the web interface for iCloud Drive.)

So I started trying to determine why. It's a somewhat lively source of discussion - among those who've actually noticed the problem -- which is almost entirely invisible, unless you go looking for it. :/

Much of the discussion was the expected (unfortunately) reflexive "have you tried turning it off and on again?" - about killing processes, deleting various files (ex: ~/Library/Application Support/CloudDocs) and rebooting - and, as expected, none of that helped.

However, the clue I needed was in this Ask Different post: iCloud Drive stuck on “Waiting to upload”

(BTW: The only way to see that "Waiting to upload" message, is to first already know that there's a file in that state; then hover over the tiny dotted line cloud icon next to it, in Finder. Nearly-invisible errors are a terrible thing. And, unfortunately, info about iCloud Drive status icons is hard to find, and somewhat limited. Note also: Contrary to the info in the above link, the icons are for iCloud Drive, regardless whether the sub-feature of Desktop and Documents is specifically enabled - in my case, that's disabled.)

With the info gained above, I see that in all the cases that I'm dealing with - of a file stuck in "Waiting to upload" - each of them has an extended attribute com.apple.metadata:kMDItemWhereFroms which is _very large_.

It does not contain, as expected, a URL of where the document came from - but it actually apparently contains another copy of the full document. :/

This metadata is also apparently unexpected / dysfunctional, since even though it shows via ls or xattr, the mdls command ignores it.

So now I'm even more sure, that this extended attribute is disposable. One last question: Does removing it, update the "modified" timestamp (which is useful info that I want to preserve)? Thankfully, some testing shows that the timestamp is unchanged.

So what I did (standard disclaimers apply - use at your own risk) to find and fix all such files in my iCloud Drive directory, was something like this:

find ~/Library/Mobile\ Documents/com\~apple\~CloudDocs \
    -type f \
    -xattrname com.apple.metadata:kMDItemWhereFroms \
    -print | while read -r thePath; do
        testVal=$(xattr -lp com.apple.metadata:kMDItemWhereFroms "$thePath" 2>/dev/null | \
            head -5 | tail -4 | sed 's/^.* |//;s/|$//' | tr -d '\n')
        if [ $(echo "$testVal" | grep -E -c 'data:(application|attachment)') -gt 0 ] ; then
            echo 'BEFORE:'
            ls -l@ "$thePath"
            xattr -d com.apple.metadata:kMDItemWhereFroms "$thePath"
            echo 'AFTER:'
            ls -l@ "$thePath"
        fi
        done

Quite soon after doing the above, bird noticed and sync'ed them all. Nice.

(BTW: Check out brctl - fun to watch that _really_ verbose log - though didn't seem help in my case.)

macos term file "could not be opened because it is corrupt"

A ".term" file is a useful way to wrap up some command-line stuff, in a neat little package which requires no command-line knowledge, no luck in typing it perfectly, etc. - for some discussion, see these old Hints articles: Run shell scripts from GUI and Use partial .term files for quick… (note that the ExecutionString attribute can be anything you want…).

I was working on a new .term file, having started by duplicating a perfectly usable one - but getting this unhelpful error:

The file “test.term” could not be opened because it is corrupt.

It may have been incompletely copied from another machine.

And then _finally_ remembered that the file is XML, and ampersands have literal meaning, so must be "escaped", as in HTML, like so:

&

Hopefully, noting that here, saves someone (like myself) a bit of hair-tearing next time.

FileVault Mac, in headless mode, notifies on boot

Oh; fun!

I'm lucky enough to be experimenting with a new M1 Mac mini, and followed through the prompts (on a kinda autopilot, from setting up my own MacBook) to set it up with FileVault 2 "full-disk encryption", even though this will be a server.

So I found out the hard way, that this then requires (purposely; for security) entering a password _very_ early in the boot process - before it even gets an IP address.

Which also means no remote connection; not via Screen Sharing, or ssh - no headless.

(Note: There is a way to avoid this - for a single boot.)

But; back to the cool part; I rebooted (to apply a software update) before I remembered the above, and a few moments later, while I was trying to debug why I couldn't reach it, the mini (which was indeed headless), started playing the "Find My..." sound effect - that is a nice touch!

Touch ID becomes an annoyance, when using a MacBook in clamshell mode

For instance: It's a very cool feature, to store an auth token, which allows decryption of passcode-encrypted iWorks docs, via Touch ID.

Except if you've switched to using your MacBook in clamshell mode (i.e.: using an external display, with the lid closed) - in which case, the apps will prompt for the decryption passcode (which, optimally, would be different for each doc) -- even though, in the days before Touch ID, it would store a token accessible via KeyChain.

So, to make the switch back, to using KeyChain instead of Touch ID:

Delete all fingerprints from the Touch ID preference pane, in System Preferences. (Which, since you've switched to clamshell mode, you're rarely using anyway - if ever.)

In retrospect, kinda obvious - though this annoyance has been on my To Do list for awhile. Hopefully this tip saves someone else some trouble.

can't unlock Mac with Apple Watch anymore?

Problems with "Use your Apple Watch to unlock apps and your Mac" function of macOS?

 (In the "Security & Privacy" section of System Preferences.)

Seeing an error message like "Your Mac was unable to communicate with your Apple Watch"?

Maybe it was working before, and suddenly isn't?

Maybe you recently reset you Apple Watch? (That was the precipitating event for me.)

It took me some digging to find, so hopefully these extra breadcrumbs here, help more folks to this signal boost, for the good folks at macrumors.com, who solved the problem.

Quicksilver, Spotlight and indexing content

I've noticed that the info I care about (messages, tasks, notes, code, whatever), is spreading to quite a few documents, apps and systems - both local to the device I'm using, and remote. (Maybe in a web system - which may or may not be sync'd / cached on my local device.)

And it's increasingly common, when I'm looking for something, that I can't immediately recall which system it's in, so where to start looking.

Which of course means I now have to put aside what I was trying to do, to focus instead, on how to find the info. And then remember what I was trying to do in the first place, to resume that task - hopefully…

This kind of context-switching sometimes does result in losing the primary task. It's certainly a waste of time and energy.

So, since I use Quicksilver extensively, I started to see this new issue, as a nail, for my Quicksilver hammer…

In the back of my head, I had a recollection that, while I'd always found Spotlight limited and cumbersome, it did a great job indexing the content of apps like Notes and Reminders - two of the systems I wanted to be able to reach into.

People who use Spotlight, may be inclined to observe how well it works for them, and how mystified they are, that some of us don't use it. It's possible, that those of us not using it, have a good reason - there may also be some inertia…

Thinking of Spotlight prompted another memory, that Quicksilver might… yes; it does have a Spotlight plugin - however I got confusing results: It was not showing content (which I knew was there) from Notes or Reminders… It seems to be limited to showing results in a Finder window (vs. the main Spotlight window) - which apparently does not show "Other" content such as Notes or Reminders. :/

I do virtually all searches (including across the web) from Quicksilver. And while I'd prefer to avoid the cognitive cost of deciding how/where to search, then launching a separate search system, and only then specifying what I wanted to find (this is backwards, for most humans) Spotlight does appear to be a better tool, for finding content.

Quicksilver is oriented more to files - and performing actions - than finding content. (Perhaps someone will point out that this too is a misunderstanding. :) )

Another plus for Spotlight: It's available (by default) on iOS as well as macOS, so as I move among those devices, Spotlight is right there.

Time to at least consider, that there are different kinds of nails, and different hammers - some of which, we thought we knew.

hdiutil Error 110: image not recognized

A script to keep a disk image (AKA dmg) mounted, was suddenly failing - silently.

(Why create such a script? In this use-case, the image / volume should only be mounted when the app using it, is frontmost and might need it; otherwise it should be dismounted - so that it may be safely mounted by another Mac. Since there's no file-locking in this scenario, mounting it on multiple Macs simultaneously, can result in conflicts. Since this is a sparsebundle, conflicts result in multiple bands, which is usually (somewhat) straightforward to sort out - but manually, and who wants that?)

I ran the script in a debug / trace mode (bash -x) and saw nothing interesting - except then I noticed:

hdiutil attach -quiet -noautoopen /path/here

Ah yes; after debugging the previous issue, I'd set -quiet, to make the output cleaner.

(BTW: The -noautoopen option is handy, since without it, the Finder otherwise can open a window for the top level of the volume - right in front of whatever it was you were working on.)

So I ran that command with -verbose instead - and got this error message:

Error 110 (image not recognized).

Which didn't get me far; I couldn't find any references that helped, especially since the image mounted OK from the GUI - at which point I realized the problem:

It worked in the GUI, because /path/here was an alias - however the script did not know how to resolve an alias; it needed a symlink instead - which the GUI happily also recognizes. A symlink just isn't be able to auto-update, as an alias can, if the target is moved. (Side note: symlinks can be _much_ smaller; handy on a small filesystem.)