I started out with this project using my 2014 iMac 5k. It’s a pretty nicely specced out machine particularly for the time, a 4GHz 4-core i7 with 32GB RAM, and a 1TB SSD drive. About as good as it got back in 2014. I think it was the first year of the slimline iMacs. But for video production, there are a few bottlenecks with this machine. One is the editing and encoding, both of which take a long time with files in the tens of gigabytes size. 1TB isn’t much to work with either, once you get those large files, so you have to work across the network to a NAS of some kind, and then the 1Gbit/s network also gets in the way. I could alleviate that somewhat with a Sonnet 10 Gb ethernet interface for Thunderbolt 2, getting around 250-300 MB/sec. I guess you see where this is going…Continue reading “The Desktop”
It seems that if you record a zoom video meeting and then interrupt the file conversion after the meeting, the video file may disappear from zoom, so you can’t restart the conversion later. At least, that happened to me.
If you go looking for the unconverted files, you’ll find them, on MacOS, in the folder ~/Documents/Zoom/<date> <time> <meeting name>. In there you’ll find, among other things, a file named double_click_to_convert_01.zoom.
So, naturally, you double-click it, but that will only get you errors. No application is set to handle files with the “.zoom” extension. A search on the net give me dozens of articles telling me to double-click it anyhow. Won’t work. Dragging the file over the Zoom.us app doesn’t do anything either.
But, a little spelunking in the Zoom.us app shows us they’ve hidden a transcoder inside it at:
If you run that app from the commandline with the raw videofile as argument, it does convert the file just fine.
I think Zoom forgot to associate the “.zoom” file extension with this Transcode app in the installation script, but now I’ve described it here, I won’t forget for the next time. Example command line (all on one line):
/Applications/zoom.us.app/Contents/Frameworks/Transcode.app ~/Documents/Zoom/2020-04-16\ 16.30.10\ Martin\ Wehlou's\ Zoom\ Meeting\ 94043638090/double_click_to_convert_01.zoom
I’ve got a new Mac Mini, and it has a gloriously low power consumption. At least it had for a while. If you wait long enough, it starts consuming power like crazy. See the graph of total power consumption to see the problem:
Now, looking at the processes, one process sticks out, the “corespeechd”. Today, it consumed around 130% of a CPU, constantly. Remarkably, I have all speech-related functionality switched off, but it still does this.
The solution? Well, I don’t want to reboot the machine all the time, so I created an entry in Lingon X to killall corespeechd once a day. I think that will do it. I’d like to kill it forever, but I see no way of doing that.
Update 2019-02-02: And this is the difference it makes installing that kill command:
Update 2019-04-03: After following Marty’s suggestion (in the comments) and even after disabling my kill-script, it looks like the problem is solved:
As I already mentioned, the Mac Pro 2008 (10.10.5) I’m running the Retrospect server on, dropped its network connection for the first time in nine years (that I’m aware of) after installing Retrospect. Since then, it’s happened more than ten times, three times just during the last 24 hours.
While setting up Retrospect, I ran into a number of problems, most of which I think I solved. I’m just noting some of them here, so I can find them again. Or so you can find them, perhaps. I’ll add to this post as I encounter more oddities.
Now that Crashplan for home is gone, or at least not long for this world, a lot of people will need to find another way of backing up their stuff. It’s tempting to get angry, and there are reasons to be, but in the end you have to forget about all that and move on. Even though you may have months, or even a year, before Crashplan stops working, there is another reason you have to get something up right now, namely file histories.
When applications are in “quarantine” on OSX after being downloaded, they are run in a kind of sandbox; they’re “translocated”. You don’t really see this, but weird things then happen. For instance, Little Snitch won’t let you create “forever” rules on the fly, claiming your app isn’t in “/Applications”, which it clearly is if you check in Finder.
The problem is that the extended quarantine attribute is set, and needs to be reset (at least if you trust the application). Too bad Apple didn’t provide a GUI way of doing that, so here goes the magic incantation (assuming WebStorm is the problem in the example):
First check if the attribute is set:
Then if you see that it is, reset it:
xattr -d com.apple.quarantine /Applications/Webstorm.app/
…and there you go. Life is good again.
I have this 2008 Mac Pro running 10.10 connected to two networks, one from each interface. Now, number 1 is connected to a slower WAN, but is the route I need to take to cross a VPN tunnel to a customer site. Number 2 should be used for everything else.
My Mac Pro is an early 2008. Over the last few years, it’s been losing function by parts. It’s like chip rot. First the firewire didn’t work right, lots of transfer errors. It may even have been that way from the start, but I always thought it was the LaCie drives or firewire hubs that screwed things up. So I stopped using firewire entirely.
Then the RAID gave me trouble, which turned out to be disk bay 1 being flaky. With or without the RAID card, bay 1 would give me disk errors even after replacing the disk. The bad disks worked fine in other bays, though.
The last couple of months, the machine started beach balling a lot, getting so slow I would almost scream. Dragging selections in Muse could take ten or twenty seconds to do, while they were instantaneous on my Macbook Pro. USB started to be flaky about a year back, with bad sound quality and dropouts using a USB headset. A few years back the upper DVD reader stopped working, too.
After a couple of months, I reinstalled OS X to no effect. Running TechTool Pro and Diskwarrior on the disk had shown no significant errors, but it took forever. Very slow disk reading. I then moved my system disk from bay 4 to bay 3, and the beach balling went away immediately. So now I was down to two functioning disk bays.
I’ve been eyeing the new Mac Pro, but the lack of serious disk space keeps me from going for it. And the price, of course. Decent alternatives would be a second hand 2010 or 2012 model. Or, I figured, trying to fix my 2008. The only thing I could think of as being the cause would be the disk cable harness (unlikely), the motherboard, or the power supply. You have to start somewhere, so I figured a new motherboard would be a good thing to do. Turns out you can get them for a decent price nowadays. I found a vendor on eBay that has a stack of them for $165, and they claim they’ve been tested before shipping. So I bought one, and got it less than a week later.
Today, I switched motherboards. It’s a pretty invasive thing to do to your Mac Pro, but you can do it in two or three hours without rushing it. Nothing broke, and I’m writing this post on that machine a few hours later and everything seems to work. I’ve moved the system drive to bay 4 and the machine remains snappy. No beach balling. I’ve installed a 4 TB in the previously really bad bay 1, and it seems to work normally. I’m having a glimmer of a hope this machine will work fine for another year or two, or maybe more. At least until Apple releases a decent modern replacement (if ever…). Below you’ll find a few pics of the process.
The new board arrived completely intact and well packaged in a sealed antistatic bag.
The machine before the slaughter. Note the unused (and unusable) bay 1. Bay 4 only serves for a slow drive with some old info. That slot is pretty slow in itself, hasn’t given any errors, but lots of huge delays (beach balling).
After removing the memory risers and the cards:
Out goes the front fan:
Then the turn comes to the memory cage. There’s a trick to this involving sliding the fan into the cage after releasing a few tabs. Read up on it carefully before attempting. iFixit has a good description.
Now it’s time to remove the three heat sinks. The two CPU sinks must be removed to get the main board out of the case, so you can just as well take the third sink (north bridge) as well.
“Interestingly”, all the sinks are held in place by 3 mm in-hex screws. Three of these screws are right in between the three sinks so you need quite a long hexagonal screw driver to get them out. Luckily, the iFixit kit has both the right bit and an extender that was just long enough and narrow enough to get the job done. Most online sources say “flat screw driver”. Don’t believe them. It’s a hex you need.
The north bridge sink:
One of the CPU sinks:
Time to disconnect the antennas. Do snap a pic first so you can look up which cable went exactly where. They’re nicely labeled, but there are no markings on the boards to correspond with the cable labels. Also, the antenna cable labeled “2” is over to the side somewhere and is not connected to anything.
Now you have to take out the speaker assembly in the lower front of the case. There’s a screw holding the motherboard in place that you can’t get at otherwise.
After disconnecting a truckload of connectors and carefully wiggling for a bit, out comes the old motherboard.
A good use for old iTunes cards: scraping thermal paste from the CPUs and the Northbridge. (The north bridge isn’t necessary, since this one is on its way out, but its a good trial run for the processors.)
Use a decent cleaner and lint-free cloth to remove the rest of the old thermal paste after scraping it off with the plastic card.
One of the sinks after cleaning. Looks great!
The processors look fine, too, after cleaning:
Time to strap up before removing the processors:
An empty case with a lot of loose cables:
Putting thermal paste on the north bridge and the CPUs. I’m using the procedure recommended on the Arctic Silver site. Except I unintentionally modified it to be messier. With this procedure, very little paste goes on the sinks.
And then you put back the motherboard, the sinks and all the rest. And cross your fingers and boot. Oh, your machine now has a new serial number, but really, who cares?
I used the opportunity to blow away all the dust from all the parts using compressed and dried air. This machine has never been this clean before.
So the other day I tried upgrading my main work machine from Mavericks to Yosemite. Since we’re now at 10.10.1 I thought it might work. Not really. It took hours to install, hanging on the “4 minutes left” mark, but got through, finally. Then Mail wouldn’t work, freezing at the “updating mail database” (or something to that effect). Tried it multiple times.
This time I’d been smarter, having done the upgrade on a SuperDuper “sandbox” drive, so all I needed to do to revert was to reboot from the internal drive. Lucky for me that the “update” of the mail database hadn’t destroyed it. Worked fine on 10.9.5.
So I guess I’ll wait for 10.10.2 and try again then. Not that I think it will work.