How It Was Built Part 5

Part of How ShadePlay was built

Part 5: making it shareable

Going public

September 27

Problem. The installer was first meant for friends. Then, the same day: "get it ready to be uploaded to GitHub and made public".

Fix.

• The same standard as the maintainer's other public tools: a one-click installer, a short README, a detailed guide, this page, and an honest list of what was tested.
• The work was split: one Claude session for the app (code, tests, installer, docs) and one for the release (git, the repository, privacy scans and publishing), with written reports between them.
• Standing rules for both: tests fake the system, nothing is downloaded without the maintainer's OK, the maintainer's apps are never stopped without asking, and every file name must work on both Windows and macOS.
• Nothing is published until the maintainer says "go".

The name

September 27

• The maintainer chose the name ShadePlay.
• The README says plainly that ShadePlay is not affiliated with or endorsed by NVIDIA; ShadowPlay and GeForce are NVIDIA trademarks.
• The README's first line says what the app is, because a couple of unrelated small projects on GitHub share the name.

Credit, and whose name is on it

September 27

• The README byline and the installer's publisher read "baddo & Claude".
• The license is MIT, "Copyright (c) 2026 baddo". An AI can't hold copyright.
• Claude is always introduced as "Claude, an AI model made by Anthropic", and nothing may suggest that Anthropic publishes, endorses or supports ShadePlay.
• Only the maintainer's public name appears anywhere public: in the code, the docs, the images, the program files and the commit history.

Moving the private install over

September 28

Problem. Before it had its public name, ShadePlay ran on the maintainer's PC as a private build called Hindsight, with its own settings folder, clips folder and start-with-Windows entries. The first start of the installed ShadePlay must take all of that over, safely.

Fix. On the first start of the main copy, ShadePlay:

1. asks the running old build to quit, and waits up to 100 seconds. If it keeps running, ShadePlay doesn't start, so two recorders never run at the same time;
2. moves the settings folder (one rename; if that fails, it copies the settings and leaves the old folder alone);
3. renames the default clips folder, never copying and deleting, and updates the paths inside the clips' sidecar files;
4. removes the old start-with-Windows entries, keeping a "turned off in Startup apps" choice;
5. from then on, makes an old build that is started by accident exit at once.

It touches only what is recognisably the old app's (its settings file, its sidecar files, its program started with Windows), never replaces a ShadePlay file, and never deletes old data or clips. Test copies, and copies in development, temporary or synced folders, skip it entirely.

The release review found holes here too: the old program could start again and re-add itself at logon, a failed rename of the clips folder was effectively never retried, a "startup off" choice was dropped, and a start that was blocked gave no feedback. All were fixed. So far the move-over has been tested only against fakes. It runs for real when the maintainer starts ShadePlay for the first time (Part 6).

A one-click installer

September 28

Problem. The maintainer wanted "an exe or msi that installs everything", and that starts with Windows.

Fix. A Setup.exe, made with Inno Setup:

• It installs per user, with no administrator rights, into %LOCALAPPDATA%\Programs\ShadePlay.
• It needs 64-bit Windows 10 version 2004 or newer, because the per-program audio recording needs it. Windows on Arm is refused, because no supported video encoder exists there; the release review caught that Setup first allowed it.
• A running ShadePlay is closed first with its own quit command, which finishes any clip being written, behind a "Closing ShadePlay" page. Setup waits up to 100 seconds: the app's 90-second limit for saves, plus a margin.
• A silent first install, as package managers run it, starts nothing. A silent upgrade restarts ShadePlay only if it was running.
• The app registers start-with-Windows itself, on its first run.
• Uninstalling removes ShadePlay's start-with-Windows entries, asks whether to delete the settings as well (No is the default), and never touches your clips.
• The release build checks that all seven copies of the version number agree, and that the FFmpeg DLLs match their notices. The review found that this check first looked at only three of the seven, and that the installer could freeze in a wait loop.

The first scratch installer was tested silently: installed, run as a test copy and uninstalled three times, with the maintainer's own start-up entries identical before and after. The interactive pages still need a hands-on test. The installer isn't code-signed, so Windows SmartScreen asks you to choose More info > Run anyway, and Smart App Control blocks it.

No personal information

September 28

Problem. A project built on one person's PC collects that person's details: in comments, in defaults and even in the program file.

What we found.

• About 30 code comments in 20 files named the maintainer's own devices or PC.
• The default never-record list contained the maintainer's own device.
• A start-up rule matched a folder that only exists on the maintainer's PC.
• The program file contained the full path of its debug-symbol file, and that path includes the Windows user name.
• The private working notes (design notes, research notes and handoffs) name devices hundreds of times.

Fix.

• The comments were rewritten in neutral words. Tests use invented devices, such as "Headset Earphone (USB Headset)", "Speakers (Bass Shaker PRO)" and a "Contoso 27Q" monitor.
• The default never-record list is empty, and a list you saved is kept.
• The folder rule now looks for a sync tool's marker file instead.
• The program records only the file name of its debug symbols, not the folder.
• The private notes are never published.
• A scan of every publishable file for the maintainer's identifiers found nothing, and the release process repeats it before publishing.

Licences, and a GPL surprise

September 27 and 28

Problem. ShadePlay is MIT-licensed, and it ships FFmpeg's DLLs. FFmpeg is LGPL, which allows that as long as the DLLs stay replaceable and their source is offered. Until the release work, ShadePlay used a well-known prebuilt "LGPL" FFmpeg for Windows, and ffmpeg -buildconf showed no --enable-gpl. Claude took that as proof.

What we found. The release review read the DLLs themselves, not the build's description of itself. One of them contained FFTW, a GPL library, pulled in by the Chromaprint library that a general-purpose build enables. That put the whole DLL under the GPL. The same build also carried about 70 other libraries ShadePlay never uses, each with a notice that would have had to ship, and a 117 MB set of DLLs.

Fix. The maintainer chose the clean way: ShadePlay's own minimal build of FFmpeg.

• Five official source archives: FFmpeg 8.1.3, Opus, NVIDIA's and AMD's encoder interface headers, and Intel's VPL dispatcher. Each is checked before use against its published SHA-256 or signature where the project publishes one (Intel's libvpl tag archive has none; its hash is recorded in BUILDING.md and checked by the script).
• tools/build_ffmpeg.sh configures FFmpeg with --disable-everything, then turns on exactly what ShadePlay uses: the NVENC, AMF and Quick Sync encoders, GPU decoding for the optional YouTube copy, AAC, FLAC and Opus audio, the MP4 format and the resampler. It refuses to finish unless the licence is "LGPL version 2.1 or later".
• No new build tools: the build uses the same compiler as ShadePlay itself. Without NASM, FFmpeg's hand-written assembly is off; the video work runs on the graphics card anyway. Measured on the test PC, encoding a clip's five audio tracks got faster with the new build (2.4 s against 3.1 s of processor time for 60 seconds of each track). The resampler got slower, but only from 13 ms to 71 ms per minute of audio, which is about 0.1 % of one processor core per sound source.
• No user names or build folders inside the DLLs: every path FFmpeg records is relative, and the script scans its output before it finishes. The same sources give byte-identical DLLs.
• The four DLLs shrank from 117 MB to under 10 MB, and the third-party notices from about 70 libraries to 4.
• FFmpeg's small software MPEG-4 codec is included for one reason: the unit tests need a processor-only encoder to make real video packets for the save path. ShadePlay itself never uses it.
• The complete source of the DLLs (the archives exactly as downloaded, plus the script) is attached to every release.

The lesson is in When the AI got it wrong: a build's own description of its licence is not proof. Read what is actually inside.

Checking for updates

September 28

Problem. A recorder that people install once and forget needs a way to hear about fixes. It must not nag, must not install anything unchecked, and must never stop recording at a bad moment.

Fix. The same update check as the maintainer's other open-source tools, written again in C++:

• Only the installed copy checks: about 30 seconds after it starts, then once a day, one request to GitHub that carries only the app's name and version.
• A newer version shows a red ! on the tray icon, Update to X.Y.Z in the tray menu and a bar in the settings window. Never a pop-up.
• Update now downloads the installer only from GitHub's own addresses, checks its size and the SHA-256 fingerprint GitHub publishes for it, checks it again right before it starts, and installs it silently. ShadePlay is back in a few seconds; the replay in memory is not kept, and the bar says so.
• Automatic updates are off by default and offered once. When they are on, they wait for five quiet minutes: no game, no clip being saved, and the settings window closed.
• A review of the automatic updates in that other tool had just found rough edges, so ShadePlay's version was built without them from the start: a failed automatic update is remembered and never retried by itself, a short network error only postpones it, turning the switch off mid-download stops it, and test copies never update themselves.
• The tests run the whole update logic against a fake network, so no test ever reaches the internet. A rehearsal with two real installers and a local fake release is prepared; it needs the maintainer at the PC.

Simple, honest docs

September 27 and 28

• "Make sure to include details on the GitHub about why I don't like ShadowPlay": the README's "Why I made this", in the maintainer's own voice, kept to the maintainer's own experience.
• "Also include performance impact numbers": only measured numbers, with their conditions. The frame-rate test that hasn't happened yet is listed as not done.
• A list of exactly what was tested, what should also work, and what is experimental.
• A detailed guide in short pages, this page, and the developer docs. A test keeps the commands in the docs valid.
• Version 0.1.0, the maintainer's choice: honest for software that was tested on one PC, with AMD and Intel still experimental.

Built with AI, open to feedback

September 28

Problem. The request for the release: "detailed wiki, why we did it, transparent AI use", and "cleaned out personal information".

Fix.

• The README and this page say plainly how ShadePlay was built, and by whom.
• Send feedback / report a bug in the tray menu opens GitHub's page for new issues in your browser, where you pick a bug report, a hardware report or an idea. ShadePlay attaches and sends nothing itself. If no browser opens, the settings window shows the address instead.
• Nothing is sent automatically, and the docs remind you to read a log before you attach it: file paths in it can contain your Windows user name.

---

---

<- Part 4: sound, saving and the app | Contents | Part 6: what is still open ->