How to fix slow loading when trying to take a screenshot with CMD+SHIFT+4

I don’t know how common this is, but I wanted to share a tip that I recently learned about how to fix slow loading when trying to take a screenshot with the CMD+SHIFT+4 shortcut. It used to pop up the selector instantly, but recently I noticed it was taking multiple seconds to load up. Nothing earth shattering, but annoying and taking me out of my flow state. Here’s how I fixed it.

Load up the full screenshot panel using CMD+SHIFT+5 (note the 5, rather than 4) and see what your microphone is set to. If it’s set to anything other than None, set it _to_ None and then hit the Esc key a few times to exit out of there. Now try doing your CMD+SHIFT+4 again and it should pop up nearly instantly.

Before: A Revelator Dynamic microphone is selected
After: No microphone is selected

My assumption on why this works is that if you have a microphone configured, it probably needs to physically interface with the device and initializing hardware can sometimes take a few seconds. Having a microphone might be useful if you’re doing a screen recording using CMD+SHIFT+5 but the ...+4 option doesn’t do any video, so microphones are really not necessary here. It would be great if Apple bypassed this check already since it’s completely useless, but as it stands today, this should get your screenshot taking back instantly.

How to use an SMB share on your NAS with Jellyfin on Windows

After the recent privacy controversy, I decided that it was time to find a replacement for Plex. Many recommendations pointed me to Jellyfin, a system which was forked from Emby, which itself was forked from Plex. I installed it, and started adding my libraries, but quickly found out that the content I had saved on my NAS was not able to be easily mounted (or so I thought). It turns out that Jellyfin really doesn’t want you to use SMB shares, even mounted network drives, but no matter, we’re professionals here. And so I’m going to show you how to use an SMB share on your NAS with Jellyfin on Windows.

We’re going to accomplish this by using a fun trick called a symbolic link. You can think of a symbolic link like an operating system-level path redirection, where one location is sym-linked (or mounted) to a link somewhere else. So for example, if you have a C: drive and an X: drive, but you really only ever want to use C:, you can mount that X: drive to a folder, let’s call it x-drive (but in reality, it can be anything you want) in C: so that to any application, you would browse to C:\x-drive and you would see the contents of X:. Crucially, the application has no knowledge of the symlink, it just sees it as a regular folder in C:. Crucially though, you are not limited to only mounting physical drives in other places; you can also mount network locations via symlinks.

Do you see where we’re going with this? We’re going to mount the SMB folder into a folder on a local drive and Jellyfin will see it as just another folder.

  1. Make sure the Jellyfin service is running as an actual user, and not the SYSTEM account. You can verify (and change, if necessary) by opening the Services MMC (Start -> Run -> services.msc). Preferably, set it to use the same user account you actually login to your computer with. This will make it easier for the following steps.
  2. Ensure that on your NAS, there is a user account created there (and this is crucial) with the exact same username and password as your PC. They must match character-for-character. So if your username on your PC is bobjones and your password is Q!W@e3r4T%Y^U&I* the account on your NAS should be bobjones and Q!W@e3r4T%Y^U&I* too.
  3. Open a PowerShell prompt as an adminstrator
  4. Decide on the local physical drive and folder name you’d like to mount the network folder to, and then have the network path to the folder ready. In this example, I’ll use C:\NAS for the local location, and \\NAS-01\Files, but remember that the local location can be any folder you want, as long as it does NOT currently exist; this process will create the mounted folder and will fail if you try to mount the network folder to a folder that already exists.
  5. In PowerShell, enter the following command:
    New-Item -ItemType SymbolicLink -Path C:\NAS\ -Target \\NAS-01\Files
  6. Open the Jellyfin console and confirm that you can now see C:\NAS (or whatever you decided to call your mountpoint)

The fact that this works as flawlessly as it does just tells me that there is no technical limitation to doing this but that rather the Jellyfin developers — for whatever reason — just simply don’t want to support it. I’ve worked in a number of roles where limiting the scope was necessary, but it’s confusing to me that they would do so for such a common type of network storage.

At any rate, I hope this article was helpful and that you are now able to use an SMB share on your NAS with Jellyfin on Windows.

Find a missing EC2 instance in AWS using just the command line

Today we found ourselves in a position where we had a Windows server – with only the Server Core experience installed – somewhere in EC2 but we could not figure out what AWS account it actually lived in. This meant that we were limiting to finding the missing EC2 instance in AWS using just the command line.

Most cloud providers offer an instance metadata endpoint that you can query to get some basic info about the instance itself. It usually operates on http://169.254.169.254 (that IP is not a placeholder, it’s literally the IP you query) and AWS is no different. As per the AWS documentation, if you hit http://169.254.169.254/latest/meta-data/ you can get some information about the running instance which was exactly what we needed.

The first thing we knew is that we needed to be in PowerShell, since the basic Windows command line doesn’t have an HTTP client.

Microsoft Windows [Version 10.0.20348.1070]
(c) Microsoft Corporation. All rights reserved.

C:\Users\nexxai>powershell.exe
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\nexxai>

Next, we tried to use the Invoke-WebRequest cmdlet, except being Server Core, it did not have the Internet Explorer (lol) components installed that this cmdlet apparently needs.

Thinking on our feet, we considered that maybe the Invoke-RestMethod cmdlet didn’t have the IE dependency since it was strictly used for REST-based calls and may have be implemented without any IE components. Success.

PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/

We tried a couple of different endpoints, but then saw the iam entry and gave it a shot.

PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/iam/
info
security-credentials/

Then naturally we checked out info.

PS C:\Users\nexxai>Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/iam/info

I can’t share the results of this command for obvious reasons, but contained within the results was the ARN of the IAM role that the EC2 instance was associated with, which – and here’s the important part – includes the account number! Yes!

After some more digging, it turns if you have the AWS CLI installed on the VM (unsure if this is installed by default), you can also run aws sts get-caller-identity which will show the account the instance is running in.

Once we were able to get the account number, we were quickly able to locate the rogue instance and deal with the original problem we were searching it out for. I hope you never have to try and find a missing EC2 instance using just the command line, but if so, hopefully we’ve just made it a little easier to do so.

Posts navigation