This past week, Apple announced their first ARM M1 based computers, also called “Apple silicon”. As expected, they’re pretty good. Not so expected is just how much better they are than the previous Intel-based machines. It’s an understatement to say that the Intel machines were blown away (somewhat to my chagrin).Continue reading “Apple M1 and the future”
When you do video production of any kind, you quickly run into two problems, namely having the files organized so that you can effectively find them, and secondly, the insane volumes of data to manage. I sortof knew that movie studios had massive data volumes, but I didn’t realize that even a moderate operation like ours would produce so much data.Continue reading “Storage and backups”
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.