Thankfully, Sean Werkema released the source code for version 1.4.0 under the MIT License (seanofw/spacemonger1).

Meet SpaceWindow

SpaceWindow is a remake written in C++20 with WinUI 3 and Direct2D, for x64 and ARM64, with macOS and Linux versions in the works.

What's new:

• Treemap, pie chart and inverted pie chart views
• As administrator, whole NTFS drives are read straight from the master file table (MFT)
• Reload reads only what changed, using the NTFS change journal or folder watching
• Themes (Windows light and dark, Dracula, Alucard or your own) and optional background animations
• Full keyboard navigation

At a glance

Where the speed comes from

Reading the MFT. As administrator, SpaceWindow doesn't open a single folder. It reads the drive's master file table, where NTFS keeps every file's names, sizes and attributes, in 4 MB blocks with six reads in flight, and decodes each block on four cores while the next ones arrive. The tree is assembled in parallel too, with every hard-linked file counted once, so the whole scan takes little longer than the disk takes to hand over the table: 2.8 million records of 1 KB on my drive.

Reloading only what changed. The NTFS change journal lists every file changed since the last scan, so Reload reads just those files and patches the folders they're in. The tree keeps an index of its folders and large files between reloads, so the work grows with what changed rather than with the size of the drive. If the journal can't tell (it was reset, or too much changed), Reload scans the drive again. Where there is no journal to use (a single folder, a network share, or a scan without administrator rights) the scanned folder is watched from the moment the scan starts, and Reload re-lists only the folders that changed.

Listing folders in parallel. Without administrator rights, a pool of worker threads shares a queue of folders: three for every four cores on SSDs, more on network shares to hide their latency, and only two on spinning disks, where parallel reads would make the heads seek. Each listing returns thousands of entries per system call, along with every file's allocation size and reparse tag, so no file has to be opened. Each folder is totalled and sorted by whichever thread finishes its last sub-folder, so there's no second pass over the tree.

Benchmarks

Both programs scanning the whole of a 1 TB NVMe system drive with 1.94 million files, on a 16-thread Ryzen 9 6900HS with a warm file-system cache, the median of three runs. SpaceWindow is timed from the moment it starts, so its start-up counts against it:

• Full scan as administrator: 32.2 s → 2.5 s (13× faster)
• Full scan as a standard user: 31.0 s → 4.8 s (6.5× faster)
• Scanner alone on C:\Windows: 4.75 s → 0.445 s (10.7× faster)
• Reload after changes: about 0.1 s instead of a full rescan

The trade-off is memory: peak use roughly doubles, 509–606 MB against SpaceMonger's 254–264 MB. SpaceWindow is a 64-bit program that keeps more about each file (its size on disk, and the IDs that hard links and reloads need) and draws with WinUI and Direct3D.

Get it

SpaceWindow is free and open source under the MIT License, available as an installer or a portable zip from the releases page. It needs Windows 11 on x64 or ARM64. The downloads aren't code-signed yet, so SmartScreen may say "Windows protected your PC": choose More info, then Run anyway.

Big thanks to Sean Werkema for the original program and for releasing its source.

Feel free to check it out and send feedback — I'm always looking for ways to improve my work. The full project is on GitHub: TechieAndroid/SpaceWindow, and I also shared it on LinkedIn.

What an in-place upgrade actually does

Windows Setup builds a brand-new C:\Windows system folder from the installation media, moves your apps, files and settings into it, and sets the previous installation aside as C:\Windows.old. Every system file comes from a clean copy, and the clutter that builds up over years of updates stays behind: superseded versions of system components, old update caches and logs. Windows normally keeps superseded components for a while so updates can be rolled back (Microsoft Learn: Clean Up the WinSxS Folder). A rebuilt system folder starts without them.

Depending on the media you use, it runs either as an upgrade to a newer build or as a reinstall of the build you already have. Both rebuild the system folder the same way and give you the same benefits.

Start with the built-in repair tools

For a quick fix, run Windows’ own repair commands from an elevated Terminal first:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

DISM repairs the Windows component store, the local source Windows uses for clean copies of system files (Microsoft Learn: Repair a Windows Image). System File Checker then scans every protected system file and replaces incorrect versions (Microsoft Learn: sfc). These tools fix corruption, but they only repair what’s already there. They don’t clear out years of accumulated clutter, and they can come up short when the damage runs deep. Repair commands only get you so far. An in-place upgrade gets you farther.

A shortcut on Windows 11: Settings › System › Recovery › Fix problems using Windows Update › Reinstall now performs a similar repair reinstall of the version you’re running, downloaded through Windows Update, with no ISO needed. It requires Windows 11 version 22H2 or later with the February 2024 optional update or newer (Microsoft Support: Fix issues by reinstalling the current version of Windows). The ISO method below doesn’t need those updates, and it can also move you to a newer build.

Before you start

• Back up anything important. An in-place upgrade is designed to keep everything, but no system-level repair is risk-free.
• Use matching media. To keep your apps and files, the media must match your installation’s language and architecture, and be the same or a newer version of Windows. If Setup won’t offer to keep your apps and files, mismatched media is the usual cause.
• Leave plenty of free space. Setup needs room for the new system folder while it keeps the old one.
• Have your BitLocker recovery key handy if the drive is encrypted, and plug laptops into power.

How to run it

1. Download the installation media. On Microsoft’s Windows 11 download page, use the Media Creation Tool and choose ISO file, or download the disk image (ISO) directly from the same page. The tool needs a 64-bit PC running Windows 10 version 2004 or later, and it only creates media for x64 processors.
2. Mount the ISO. Right-click the file and choose Mount. Windows opens it as a virtual DVD drive that you can browse in File Explorer.
3. Run Setup from within Windows. Open the drive and run setup.exe. Booting from the media instead only offers a clean install.
4. Keep everything. Follow the prompts, and when Setup asks what to keep, choose Keep personal files and apps.
5. Let it finish. The PC restarts several times along the way. Afterwards, run Windows Update and check that your apps and devices work.

Before and after on my PC

Here’s what an in-place upgrade did on one of my own machines. This one also moved the PC to a newer Windows 11 build.

Side by side, here are the totals from those two Properties windows:

The rebuilt system folder holds far fewer folders and files. Part of that drop is old copies of apps and user folders, since C:\Windows.old holds the whole previous installation (see the caption above); the rest is accumulated clutter that didn’t make the trip. That’s less for Windows servicing, antivirus scans and backups to work through.

Both size figures went up, by about 13–14 GB. Size is a poor measure of clutter here, though: File Explorer counts a hard-linked file once for every place it appears, so its figures for the Windows folder overstate what’s actually on disk (Microsoft Learn: Determine the Actual Size of the WinSxS Folder). The file and folder counts are the better yardstick.

Cleaning up afterwards

Keep C:\Windows.old until you’re sure everything works. It’s what Windows uses if you choose to go back under Settings › System › Recovery, and by default that option lasts 10 days (Microsoft Learn: DISM Operating System Uninstall Command-Line Options). To reclaim the space sooner, go to Settings › System › Storage › Temporary files and select Previous Windows installation(s).

The bottom line

Repair commands fix individual broken files. An in-place upgrade replaces the whole system folder with a clean one, which is as close as you can get to a fresh install without losing your apps, files and settings. Make it your next step before you reach for a full wipe.

Microsoft documentation

• Repair a Windows Image (DISM)
• sfc (System File Checker)
• Clean Up the WinSxS Folder
• Determine the Actual Size of the WinSxS Folder
• DISM Operating System Uninstall Command-Line Options
• Fix issues by reinstalling the current version of Windows (Microsoft Support)
• Download Windows 11 (Media Creation Tool and ISO)

The Stack

Everything runs on my main server — a Ryzen 5 8600G with 16GB RAM. The full stack ended up being:

• vsftpd — FTP server that receives recordings directly from the cameras
• go2rtc — RTSP-to-WebRTC bridge for live streaming
• nginx — serves the frontend and proxies the go2rtc WebSocket
• Docker Compose — ties nginx and go2rtc together
• A single-file vanilla JS/HTML frontend — no frameworks, no build step

Step 1: FTP Server for Camera Uploads

The Reolink cameras support FTP upload for recordings and snapshots. I set up vsftpd on the server with anonymous upload enabled, pointed at /disks/nvme2tb/NVR/ with subdirectories for each camera.

Getting vsftpd to cooperate with the Reolink firmware took more debugging than expected. The cameras insist on attempting AUTH TLS before every connection, which caused vsftpd to respond with a 530 error and leave the camera stuck in a login loop. The fix was enabling SSL properly with a self-signed cert and setting force_anon_logins_ssl=NO and force_anon_data_ssl=NO — letting TLS negotiate without requiring it.

The other gotcha was vsftpd's chroot security check. The anon_root directory can't be writable, so the solution was to make /disks/nvme2tb/NVR owned by root with 755 permissions, while the actual camera subdirectories (Front/ and Rear/) are owned by the ftp user and fully writable.

The final vsftpd config that works:

anonymous_enable=YES
no_anon_password=YES
anon_root=/disks/nvme2tb/NVR
anon_upload_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES
write_enable=YES
local_enable=NO
ssl_enable=YES
allow_anon_ssl=YES
force_anon_logins_ssl=NO
force_anon_data_ssl=NO
require_ssl_reuse=NO
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
pasv_address=192.168.50.61
seccomp_sandbox=NO
isolate_network=NO
pam_service_name=vsftpd

Three lines in there deserve a note before you copy them. seccomp_sandbox=NO and isolate_network=NO turn off two of vsftpd's extra sandboxing layers; that's acceptable on a server that only listens on your LAN, but leave them at their defaults on anything that faces the internet. The same goes for anonymous upload with no password: it works here because nothing outside my network can reach the server, so on a network you share with people you don't trust, give the cameras a real FTP account instead. And pasv_address is the server's own LAN address, so put yours there.

The cameras auto-organize uploads into Front/YYYY/MM/DD/ and Rear/YYYY/MM/DD/ directories, which made building the date browser in the frontend trivial.

Step 2: The Frontend Gallery

Rather than reaching for a framework, I wrote the entire frontend as a single index.html served by nginx. It fetches nginx's JSON autoindex output to walk the directory tree and build the file list entirely client-side.

Key features:

Recordings browser — files grouped by time of day (Morning / Afternoon / Evening / Night), paginated at 48 per page with options up to "All". Each card shows the camera name, file size, date, and time in 12-hour format extracted from the filename.

Video thumbnails — generated client-side using a hidden <video> element and <canvas>. An IntersectionObserver queues thumbnail generation only as cards scroll into view, with a concurrency limit of 3 simultaneous extractions to avoid overwhelming the browser. Generated thumbnails are cached in memory so switching filters and pages doesn't re-generate them.

Bookmarks — a ☆ icon on each card that fills to ★ when clicked. Bookmarks persist in localStorage and a dedicated filter button shows only saved items.

Today summary — when viewing all cameras with no filters, a summary bar at the top shows today's file counts, video/image breakdown, and total storage consumed.

Modal viewer — click any card to open it fullscreen with keyboard navigation (← / → arrows), a download button, and prev/next controls.

Step 3: Live Streaming with go2rtc

The cameras expose RTSP streams at port 554. Browsers can't consume RTSP directly, so I added go2rtc to the Docker Compose stack. It pulls the RTSP stream from each camera and serves it over WebRTC via a WebSocket signaling channel.

The cameras shoot H.265 at 2560×1920 / 25fps / 8192 Kbps. Firefox doesn't support H.265 in WebRTC at all, and Chrome on some platforms is hit-or-miss, so I configured go2rtc to transcode to H.264 using the Ryzen's integrated GPU via VAAPI:

streams:
  front:
    - rtsp://admin:PASSWORD@192.168.50.125:554/h264Preview_01_main
    - ffmpeg:front#video=h264#hardware=vaapi#audio=opus
  rear:
    - rtsp://admin:PASSWORD@192.168.50.246:554/h264Preview_01_main
    - ffmpeg:rear#video=h264#hardware=vaapi#audio=opus

ffmpeg:
  h264: "-codec:v h264_vaapi -g:v 25 -keyint_min:v 25 -force_key_frames:v expr:gte(t\\,n_forced*1) -preset:v fast -profile:v baseline -level:v 3.1"

The forced keyframe every second (-g:v 25 at 25fps) was critical — without it, new WebRTC connections would often render a grey corrupted frame for several seconds while waiting for the camera's natural IDR keyframe interval.

The WebRTC signaling in the frontend connects directly to go2rtc's WebSocket API at /api/ws?src=front&video=h264&audio=opus, explicitly requesting the H.264 track:

const ws = new WebSocket(`ws://${location.host}/api/ws?src=${cam}&video=h264&audio=opus`);

ws.onopen = async () => {
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  ws.send(JSON.stringify({ type: 'webrtc/offer', value: offer.sdp }));
};

ws.onmessage = async e => {
  const msg = JSON.parse(e.data);
  if (msg.type === 'webrtc/answer')
    await pc.setRemoteDescription({ type: 'answer', sdp: msg.value });
  else if (msg.type === 'webrtc/candidate')
    await pc.addIceCandidate({ candidate: msg.value, sdpMid: '0' });
};

Streams auto-reconnect on disconnect, show a live clock timestamp overlay, and have a fullscreen button.

Step 4: Stats and Cleanup

The Stats tab shows total file counts, per-camera storage breakdown, and a 30-day bar chart of recordings per day. Clicking any bar drills into that day's detail — files by type, size, camera, and time-of-day distribution.

For storage management I wrote a simple cleanup script that removes mp4 files older than 7 days from both camera directories and cleans up empty date folders:

mapfile -t FILES < <(find "$CAM_DIR" -type f -name "*.mp4" -mtime +7)
for f in "${FILES[@]}"; do
    SZ=$(stat -c%s "$f")
    TOTAL_BYTES=$((TOTAL_BYTES + SZ))
    rm -f "$f"
done
find "$CAM_DIR" -mindepth 1 -type d -empty -delete

Calculating sizes before deletion (not after) was the key detail — du on already-deleted files returns zero.

Docker Compose

The full stack is two containers:

services:
  go2rtc:
    image: alexxit/go2rtc:latest-hardware
    container_name: nvr-go2rtc
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./go2rtc.yaml:/config/go2rtc.yaml:ro

  nvr-gallery:
    image: nginx:alpine
    container_name: nvr-gallery
    ports:
      - "8889:80"
    volumes:
      - /disks/nvme2tb/NVR:/data/NVR:ro
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./gallery:/usr/share/nginx/html:ro
    depends_on:
      - go2rtc

go2rtc runs in network_mode: host so it can reach the cameras on the LAN directly and bind to the WebRTC UDP ports without NAT complications. nginx handles the gallery frontend and proxies go2rtc's API for the WebSocket signaling.

Lessons Learned

vsftpd's AUTH TLS handling — The Reolink firmware always attempts TLS negotiation. Disabling SSL entirely causes 530 Please login with USER and PASS in response to AUTH TLS, which confuses the camera firmware into an infinite reconnect loop. You have to actually enable SSL and let the handshake complete.

go2rtc signaling — The go2rtc API uses WebSocket-based signaling, not HTTP POST like older documentation suggests. The correct endpoint is /api/ws?src=STREAM_NAME with JSON messages of type webrtc/offer, webrtc/answer, and webrtc/candidate.

H.265 in browsers — Firefox doesn't support H.265 in WebRTC at all. Even in Chrome, receiving H.265 without a proper IDR keyframe produces a grey corrupted image. Transcoding to H.264 with forced keyframes solved both problems cleanly.

nftables policy drop — My server's default nftables config drops everything not explicitly allowed. FTP passive mode needs both port 21 and the PASV range (40000-40100) open, and go2rtc needs ports 1984, 8554, and 8555. Easy to miss if you're used to permissive default firewall configs.

The end result is a clean, fast, fully local NVR web interface that works on every browser and device on my network. No cloud, no subscriptions, no data leaving the house. The full project is on GitHub: TechieAndroid/nvr.