Thursday, May 05, 2016

Brother HL6180DW laser printer: manufacturing defect in foam roller in @ 2003 printers?

This post is based on my two star Amazon review of our 3yo paper-jamming Brother HL6180DW:

We've had this printer for 3 years.

Early on this printer had sleep/wake issues with our Mac. Sometime in the first year or so of use software updates fixed those.

After almost 3 years of regular home printing use it began jamming. The Drum was also due to be replaced. We replaced both the drum and the toner cartridge, but the jamming worsened until it became unusable.

Since this happened I’ve been in contact with Brother support. They requested photos of a key foam roller and they wanted the printer serial number. Even though the printer is 3 years out of warranty they said they'd mail me a refurb. Problem is -- they don't have any refurb devices, they've all been shipped out.

I think my year of this product had a manufacturing problem with a foam roller. It's visible when you open the rear port and flip out a plastic guide. It should be crinkled at the margins and smooth in the center. Ours has linear striations. There are blog posts about this problem. I think Brother offered the out-of-warranty refurb because they know printers in my model year are failing. They're unwilling to announce this however. This probably also explains the lack of refurb machines.

I'm actually ordering a new one. If they send me a refurb in the next 30 days I'll return it (so Brother will have another refurb to distribute!). If they send me a refurb 4 months from now I guess I'll have two. I'm ordering a new one because I have toner and drum components already.

If you have an older HL6180DW do these things before you order a new Drum for an old printer.

1. Check the foam roller and make sure it looks like it should (When you get a new one, photograph the roller.)
2. Check the Fuser lifespan remaining. After 3y we had 71% left. (it's in the manual).

I’ll add photos of the current foam roller condition and the new one once it arrives.

The last really good printer I owned was an Apple LaserWriter Select 360. Printers have not really improved since the early 90s, scanners stopped improving around 2000, dSLRs stopped around 2014, smartphones around 2016.

Update 5/6/2016: Very much to my surprise Brother phoned to say they were unlikely to get any more 6180DW, but they’d overnight ship me a HLL6200DW along with a toner cartridge. That’s the 6180 replacement.

Update 5/10/2016: I received my replacement HL-L6200DW. I can’t tell if it’s new or a refurb. The test print is vastly better than my aged 6180DW, there was more wrong than the paper jams. Installation was straightforward, save that one Mac gave me an annoying “unable to communicate with the printer art this time” over the WiFi interface. I reset the OS X print system then restarted the Mac and the printer and it worked.

I didn’t bother with the directions, I used the USB cable and OS X printer page to get  it on the WiFi network.

Some of the things I’ve learned:

  1. Think very carefully about replacing the Drum Unit on a 3yo printer. The Drum Unit was half the price of a new (toner-free) printer. If I hadn’t bought the Drum Unit I wouldn’t have bothered contacting Brother on an out-of-warranty device, I’d have just bought a new printer. Faster and less trouble.
  2. Brother is pretty serious about service. It took a few days of back and forth tech questions, but their responses were never unreasonable. Probably best to say you use paper they recommend when asked (in fact I did, but only by chance).
  3. I was a bit annoyed when Brother said to wait for a refurb — I pointed out I’d have to buy a printer while I waited. So that wasn’t stellar, but they then phoned and said they would send a newer model. So there’s that.
  4. It’s really dumb to think that a Drum Unit will help with paper jams if the paper isn’t jamming in the Drum Unit. Duh. I wasn’t thinking very clearly there. In my defense the Drum Unit was end-of-life, so I figured it was problem. It wasn’t.

Friday, April 22, 2016

Apple Touch ID is dangerous.

Many iOS apps, including Apple secure Notes and banking apps and 1Password.app and Apple Pay provide an option to use Touch ID for authentication. Apple makes much of the security advantages of Touch ID.

Sometimes Touch ID fails to recognize your finger. That’s no problem, you can repeat that finger recording, or you can add another one. All you need to know is your iPhone’s unlock code.

All anyone needs to know is your iPhone’s unlock code. With it can add their own finger, and unlock anything that was Touch ID enabled. In my testing on Apple’s secure Notes a fingerprint added after a Note was created opens the Note.

So Touch ID is only as secure as your iPhone’s unlock code. Which, even with Touch ID enabled, you have to enter too often. So you probably make it short and tappable so you can do that.

Yeah, once you enable Touch ID on your bank account, you’ve basically changed its password to your iPhone’s conveniently short and tappable unlock code.

Touch ID is dangerous.

Monday, April 18, 2016

Force Mac Chrome to open for a specific user profile - as of April 2016

I’ve been trying to get Chrome to open in one of my 15 user profiles since at least 2012. I have visited an open SuperUser question on this topic for four years. Today I added a method that work — for this moment:

As of April 2016 on Yosemite I was able to locate Google Apps for all of my 15 Google Profiles (yes, 15). Some were in ~/Applications/Chrome Apps, though we have been told these are going away [1].

To find all of them however I had to do this:

Go to ~/Library/Application Support/Google/Chrome.
In Spotlight search on kind:app
Find 300kb "Applications" with names like Gmail (username).
Copy the ones you want and rename them, then put in your Applications folder of choice.

All victory is transient, but Sisyphus is ahead most of the time.

Scrivener - the book compiler. Review.

I'm using Scrivener to write Smartphones for All - Using iPhone and Android to build independence for atypical minds.

It’s brilliant software. On my Mac it uses the same text editing engine as TextEdit, including the same RTF format. So, like the Nisus Writer I once used, my writing is indexable by Spotlight and almost as future-proof as plaintext. (I thought RTF was dead. Guess not.)

Apple’s text engine has its share of bugs and limitations, but for basic text work it’s good enough. The primary weakness is table layout, but so far I’ve worked around that.  Scrivener manages the tasks TextEdit can’t do, like page references, footnotes, internal links, document structure and the like.

The real brilliance though is how Scrivener merges concepts of software code management with the traditional word processor. It treats text blocks as though they were blocks of code, including simple version management and “compiling” to multiple output formats (PDF, EPUB, etc). Rather than use some horrid database store, Scrivener leverages native Mac file structures to manage its data. Extra brilliance points for that.

On this compile framework Scrivener layers a rich set of power user features. The latter, I admit, can be overwhelming. I recommend learning the basics from the initial tutorial, then start writing and learn additional features over time.

All software dies. One day Scrivener will die too. But with the ability to complete to multiple formats, and the use of native file system semantics and RTF data, Scrivener is as future proof as any power tool can be [1].

[1] Scrivener’s design is a guide to how photo management software should be built. Please, someone do this.

Thursday, April 14, 2016

The new and old and obsolete and confusing ways Mac OS X starts code running.

Windows added uninstallers at least 15 years ago. MacClassic OS didn’t need them, but Mac OS X sadly does. Indeed, it needs them more as MacOS gets more complex and less well documented:

… The difference between an agent and a daemon is that an agent can display GUI if it wants to, while a daemon can’t. The difference between an agent and a regular application is that an agent typically displays no GUI (or a very limited GUI).

… Agents run in a user context; daemons are userless and purely background, without any access to a window server or other user state. That’s why the daemon vs agent distinction in the Library folder names …

… once comprehensive daemon/agent doc was last updated in 10.5 after initial authoring for 10.4

Without an uninstaller we end up doing a hunting expedition when weird things happen. Code that starts automatically is particularly hard to track down. I wrote this post as a reference for me, drawing from a few Super User and other posts:

 This list of places to look comes from the above, some of these are extremely obscure and some may not longer be used.

  • User Login Items (~/Library/Preferences/com.apple.loginitems.plist)
  • ~/Library/LaunchDaemons
  • ~/Library/LaunchAgents
  • ~/.bash_profile
  • /Library/LaunchDaemons
  • /Library/LaunchAgents
  • /Library/StartupItems
  • /System/Library/LaunchDaemons/
  • /System/Library/LaunchAgents
  • /System/Library/StartupItems
  • /Library/Preferences/loginwindow.plist can have Login Items that apply to all users
  • /etc/profile
  • /etc/mach_init.d/
  • /etc/rc/ and /etc/rc.local - totally unsupported, and not created by default (but probably still work)
  • Network/Library/LaunchDaemons, but I don’t know)?
  • /etc/mach_init_per_login_session.d/ and /etc/mach_init_per_user.d/
  • cron launched @reboot items (yes, cron is still there), this might even work for everyone’s crontabs
  • /Library/Security/SecurityAgentPlugins that have been loaded by being listed in the proper spots in /etc/authorization
  • /private/var/root/Library/Preferences/com.apple.loginwindow.plist, in the LoginHook key (runs as root, passed the username)MCX (WorkgroupManager) login hooks (runs as root, but passed the username) note: below this network home directories are more reliably available, as is a connection to the WindowsServer
  • MenuBar items from ~/Library/Preferences/com.apple.systemuiserver.plist and /Library/Preferences/com.apple.systemuiserver.plist (+MXC added items)
  • /Library/Preferences/loginwindow.plist, in the key (array of paths) AutoLaunchedApplicationDictionary (everyone gets this launched at login, runs as user) (+MXC added items)
  • LoginItems (generally GUI items) ~/Library/Preferences/com.apple.loginitems.plist and possibly /Library/Preferences/com.apple.loginitems.plist (have not tried) (+MXC added items)

Some terminal commands can help figure out what’s running:

launchctl list

2BUA8C4S2C.com.agilebits.onepassword4-helper
ch.tripmode.TripMode.169864
com.bombich.cccuseragent.132660
com.google.Chrome.44620
com.google.GoogleDrive.49732
com.google.keystone.system.agent
com.red-sweater.crashreporter.63648
com.red-sweater.marsedit.6280
com.synology.CloudStation
com.synology.CloudStationDrive
org.openbsd.ssh-agent
ws.agile.1PasswordAgent

When I edited my ~/Library/Preferences/com.apple.loginitems.plist I found references to 4 3 apps and a server, including one I removed 7-8 years and 3 machines ago:

  • LaunchBar.app
  • /Volumes/Molly_Internal
  • /Applications/Dropbox.app
  • MagicPrefs.app

I doubt they did anything, but I edited them out anyway.

Software ages like people, with increasing mutations and unhelpful complexity. OS X is late middle age, it’s been through many handoffs, each taking its toll …

See also

Wednesday, April 13, 2016

Mac thunderbolt 2 drive dropping -- remember ScanSnap AOUMonitor and don't touch Amazon Cloud Drive.

After months of reliable use my Elgato Thunderbolt 2 hub is dropping my USB3 external SSD; just like the OWC T2 hub did in my initial testing.

We know Yosemite (and El Capitan) have issues with Thunderbolt hubs; there’s something frail in Apple’s infrastructure [1]. But it had been working… So after power cycling everything [3] it’s time to look for things that have changed recently.

The first place to look is my Login items. I find something called “Mountain”. It’s missing though. Weird. Part of something I’d tried then removed. Deleted that.

I also find AOUMonitor. That would be related to my recent ScanSnap update. Sounds familiar, so I use my Google Custom Search for everything I’ve published. I find Managing unwanted Mac startup apps: ScanSnap’s AOUMonitor and Citrix Receiver. Bang. AOUMonitor is a known bad actor. Delete it.

Next is Google Drive. It’s known to cause problems, but I’m still hooked on it and it’s an old-timer. Despite Google’s decreasing interest in iOS and OS X [2] I have to leave it.

But where’s Amazon Cloud Drive? It’s a newbie that’s also launching automatically. The fact that it’s absent from Login Items tells me it’s poorly written. Over to LaunchDaemons.

System Library\LaunchDaemons looks all Apple — as it should be.

Users\Library\LaunchDaemons has CCC (ok), Office (licensing and update, ugh), Skype (huh? - deleted!), Google keystone (old, part of their update infrastructure I think), TripMode (? delete for now), Barebones (trustworthy).

Users\me\Library is a bit odd.  Instead of LaunchDaemons we have LaunchAgents (really Apple?) [4] and no Startup Items. In LaunchAgents I find simple plists for Synology CloudStation (yeah, I’m suspicious of that one, but need it for now), 1Password (need it), Safari (ok I guess) and com.imobiesilentcleanserver.plist. The last was probably left over from testing imobie’s iOS cache cleaner (didn’t work), so I deleted it.

Alas, I still can’t figure out how Amazon Cloud Drive is starting up. Now I really want to kill it. Google is no help (which is another bad sign). Looking at Log files it looks like ACD is using some .NET infrastructure and it’s generated about 15 Console crash logs. 

Amazon Cloud Drive is a bugger to purge. EasyFind finds a folder in .local/share — yeah, a hidden directory. There’s app.com.amazon.clouddrive.mac.installer.playlist in friggin’ /private/var/db/BootCaches/2B1FD298-BBE8-4207-B1B0-ED420A2DAD74. There’s crap in Application Scripts, Application Support, and too many to mention. Try searching on “Amazon Cloud Drive”, “amazon.clouddrive” and so on. Take your time. 

Really, don’t touch Amazon Cloud Drive. Now I’m getting DOS TSR flashbacks in addition to my SCSI flashbacks.

Lastly, a safe boot to clear caches and then a restart. Now we’ll see what happens. I never did find what was launching Amazon Cloud Drive, but my Console isn’t showing any “Amazon” messages.

- fn -

[1] I’m getting PTSD flashbacks to MacOS Classic and SCSI chains.
[2] Apple is not doing well. 
[3] I’m going to start routinely power cycling my peripherals — they can go weeks without cycling whereas my Air gets cycled every week or two. 
[4] Update: jws explained -  "The difference between an agent and a daemon is that an agent can display GUI if it wants to, while a daemon can't. The difference between an agent and a regular application is that an agent typically displays no GUI (or a very limited GUI)… Agents run in a user context; daemons are userless and purely background, without any access to a window server or other user state. That’s why the daemon vs agent distinction in the Library folder names…

Tuesday, April 05, 2016

iOS 9.x spotlight bug explained: It's the RAM.

Spotlight has been failing for me since I updated to iOS 9 - no results appear. It got much worse with 9.3. Force-quitting background apps, especially Reeder.app,  helps. It acts like a limited RAM bug, but I think there are ways Spotlight may fail.

From Apple Discussions it doesn’t hit devices with 2GB of RAM, it’s a problem for 1GB devices with lots of indexed content and/or memory hogging apps.

Jason Heiser has figured out what’s wrong (emphases mine). It’s a capacity/RAM problem:

Apple discussions April 5, 2016

My iPhone 6 updated to iOS 9.3.1 an hour ago and Spotlight Search is still broken for me.

I downloaded iOS Console and looked at the console output when trying to perform a Spotlight Search. Here is what I saw:

Apr 5 15:42:18 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81448aac in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x814467cc in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81649da8 in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : Invalid offset 2170854824 into shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone ReportCrash[288] : platform_task_update_threads failed 1
Apr 5 15:42:19 jPhone ReportCrash[288] : Formulating report for process[286] searchd
Apr 5 15:42:19 jPhone ReportCrash[288] : report not saved because it is non-actionable
Apr 5 15:42:21 jPhone UserEventAgent[26] : jetsam: kernel termination snapshot being created
Apr 5 15:42:21 jPhone ReportCrash[289] : Saved type '298(298)' report (2 of max 25) at /var/mobile/Library/Logs/CrashReporter/JetsamEvent-2016-04-05-154221.ips

According to this, the searchd crash log is not being saved because it is "non-actionable." However, a log for "JetsamEvent" is being created at roughly the same time. I looked at this file on my iPhone and JetsamEvents appear to be a low-memory (RAM) issue. Here is the top portion of the crash report.


{"timestamp":"2016-04-05 15:42:21.21 -0500","bug_type":"298","os_version":"iPhone OS 9.3.1 (13E238)"}
{
"crashReporterKey" : "88540025a9600afa364c269a2c5bc8a91370b1ca",
"kernel" : "Darwin Kernel Version 15.4.0: Fri Feb 19 13:54:49 PST 2016; root:xnu-3248.41.4~28\/RELEASE_ARM64_T7000",
"product" : "iPhone7,2",
"incident" : "D0ED493F-7687-49D9-AFB9-BEE80BD93082",
"date" : "2016-04-05 15:42:21.21 -0500",
"build" : "iPhone OS 9.3.1 (13E238)",
"timeDelta" : 95,
"memoryStatus" : {
"compressorSize" : 50489,
"pageSize" : 4096,
"compressions" : 824422,
"memoryPages" : {
"active" : 101577,
"throttled" : 0,
"fileBacked" : 37711,
"wired" : 49311,
"anonymous" : 114469,
"purgeable" : 0,
"inactive" : 48272,
"free" : 2459,
"speculative" : 2331
},
"uncompressed" : 172172,
"decompressions" : 362924
},
"largestProcess" : "searchd",


According to this, the "largestProcess" was searchd when the crash report was generated. Further down in the crash report is searchd's information:


{
"rpages" : 129777,
"states" : [
"daemon"
],
"name" : "searchd",
"pid" : 286,
"reason" : "highwater",
"fds" : 100,
"uuid" : "7b301993-286d-3da5-a497-b729984d3229",
"purgeable" : 0,
"cpuTime" : 2.481274,
"lifetimeMax" : 84765
},

Apparently the maximum for searchd is "84,765" but it reached "129,777." The reason is "highwater" which I assume means searchd exceeded its RAM allotment. So maybe my Spotlight index is too large. Too many iMessages, too many songs, too many emails... Who knows.

The "report not saved because it is non-actionable" for searchd's crash report is worrisome. I fear this bug is nowhere on Apple's radar. We might be marginal outliers without recourse for a long time.

There are two workarounds for the bug:

  1. Force-quit background apps — may help free RAM. Try again.
  2. Siri works for launching apps even when spotlight fails.

I think setting all Spotlight indexing option to On helps — I have a feeling there’s a bug with rendering results that is worse if the rendering process has to manage exclusions. Restarting your phone daily probably helps too.

Update 7/30/2016

A correspondent who saw the same behavior as mine reported that Spotlight was working 8 days after he did a phone wipe and restore. I did the same and it’s working now 7 days later.  That doesn’t mean it will work forever, but 7 days is a long time. I’m now on iOS 9.3.3. I have seen a trustworthy report that the upgrade to 9.3.2 fixed the problem for some, for me it took the OS update and a wipe/restore.