v3.1.0

[3.1.0] - 2026-09-08

The clips page of 3.0 put the same thing on the screen three times. This is
that page after a tidy-up: a cut is a row, an output looks the same wherever
it shows up, and the button per action became a menu per row. Underneath,
the service learns a second platform.

Added

• Linux, first stage. The service builds, passes its tests and runs on
  Linux, and CI checks that next to Windows. The single-instance guard and
  replaycut stop work there (a lock file under $XDG_RUNTIME_DIR and
  SIGTERM), the address for other devices carries the real host name, a
  start without a terminal opens the browser like the Windows shortcut,
  the OBS profiles are read from ~/.config/obs-studio (or the Flatpak's
  copy) and the default clip folder is the XDG videos directory. Secrets,
  notifications, the clipboard under Wayland, GPU encoding through VAAPI,
  autostart, the installer and the tray follow in the next stages; until
  then those report that they are not available on this platform.

Changed

• The clips page carries less. A cut is one row now - its range, how
  long, which audio, and where its outputs went - and it opens to show them.
  An output is the same row wherever it appears: under its cut, in the
  result of the last share, on Activity. Each row has the one action you
  want (copy the link, or open the folder for a local file); everything
  rarer - the page link, download, post, publish, render to another target,
  delete - moved into a "…" menu. The four settings of the share row read as
  a sentence ("Mix (all) · H.264 · 16:9 · mark done afterwards") and open on
  "Change", and the Share button says where it is going.
• The clip list says what it knows in words instead of a wall of badges, the
  key hint on the Share button no longer fights the accent colour, and a
  section heading no longer competes with the buttons beside it.

v3.0.1

[3.0.1] - 2026-09-08

Two things 3.0.0 got wrong, found by putting a real 2.x state next to real
recordings. 3.0.0 was published but never signed, so this is the first 3.0
anyone can install.

Fixed

• Rendering a cut no longer marks its clip done. "Afterwards" belongs to the
  share row; a render often happens days later and says nothing about the
  clip. (The endpoint still takes after, the page no longer sends it.)
• The migration lists the clips whose recording is long gone. Their old
  shares hung under a clip the page never showed, so they were only
  reachable on Activity; they now appear under "Done" with their links,
  their title and the day they were recorded (read out of the file name).
  A cut from before 3.0 has no cut file, says so and offers "Marks" instead
  of "Render": the range goes back on the timeline and one Share makes it.

v3.0.0

[3.0.0] - 2026-09-08

Cut, then decide. A clip used to be one dialog on a five-minute recording:
pick a range, pick the audio, upload, and whatever you did not decide then
was gone with the recording. 3.0 puts a cut in between - the range as its
own file, the picture untouched and every audio track along - and renders
everything from that. The same cut goes to Nextcloud today and to YouTube as
a Short tomorrow, with another audio mix, long after the recording is in the
recycle bin. Save cut saves a range while you play and renders nothing;
the clips page shows what came out of every cut.

The list keeps itself: a shared clip is done and out of the way, grouped by
the evening it belongs to, one click back. Activity is the new page for
"what did I send where".

Your state moves. Titles, the seen list and the share history leave their
three JSON files for replaycut.db beside the settings. The first start
imports them and moves the old files to backup-2.x\, so an installation of
2.x that is put back finds its state where it left it. The history is no
longer capped at 200 entries.

Added

• Every share keeps its cut. The range you pick becomes a file of its
  own first - .cuts\<id>.mkv in the clip folder, the recording's picture
  and all its audio tracks, copied, not re-encoded - and the upload is
  rendered from that. So audio mode, 9:16 and quality are decisions you can
  take again later: the cut is enough, the five-minute recording is not
  needed any more.
• Save cut: save a range while you play and render it after the game -
  to any target, with another audio mix or as a Short, as often as you like.
• Shared clips leave the list. A clip you have shared is done and is out
  of the way; ?done=1 lists the done ones, and one call brings a clip back.
  "Afterwards" per share decides between keeping it, marking it done and
  moving the recording to the recycle bin - the new setting
  cleanup.afterShare (default: done) is what the share row starts with.
  cleanup.recycleDoneAfterDays does the same on a timer.
• Deleting a clip has a reach: ?scope=clip recycles only the recording and
  leaves the cuts, so the clip can still be rendered and published;
  ?scope=all (the default, as before) takes everything with it. A single
  cut can go on its own with DELETE /api/cuts/<id>.
• A recording that disappears from the folder no longer takes its cuts with
  it: the clip stays in the list, marked done, with everything it produced.
• Diagnostics: a line for the cuts - how many files, how much space, how
  many the service knows about - with a warning from 10 GB on.
• The history keeps every entry now instead of the newest 200, and
  GET /api/history takes limit and before to walk back through it.
• The clips page was rebuilt. One list with a filter (Active / Done) and
  a heading per day, badges for the cuts and the targets a clip went to; the
  clip itself shows its cuts underneath, each with what came out of it and a
  "Render" of its own. "Save cut" and "Afterwards" sit next to Share, and a
  clip whose recording is gone shows its thumbnail and keeps its cuts.
• New page: Activity. What is running with a way to cancel it, and every
  output ever made - newest first, filtered per target, one click to the clip
  it came from. It replaces the "Shared" list on the clips page.

Changed

• replaycut keeps its state in one file. Clip titles, which clips have
  already been announced and the share history moved out of three JSON files
  and into replaycut.db next to the settings. The first start of 3.0
  imports the old files and moves them to backup-2.x\, so an installation
  of 2.x put back later finds its state where it left it.
• The share progress has one more step, "Cut", before "Encode". It takes
  about a second and needs no graphics card. What comes out is frame for
  frame what 2.8 produced.

Removed

• The "Shared" section of the clips page: its entries are on Activity now,
  and under the cut they came from on the clip itself.

Fixed

• Settings: changing how long presigned S3 links stay valid can be saved
  again - the value went out as text and the service refused it.

v2.8.0

[2.8.0] - 2026-09-07

Secure by default. replaycut now listens on your PC only until you open it
up, and opening it up is one switch that asks for a password first. The
everyday way onto a phone is no longer typing that password: the phone
asks, your PC shows the request with a code and the device's name, and one
click lets it in - or the phone scans the QR code, which signs it in on the
spot. Settings lists every signed-in device and lets you sign one out.
Nothing about your clips or the sharing changed.

Added

• replaycut now listens on this PC only. A new installation is not
  reachable from the network until you turn it on - in the setup wizard or
  under Settings › Access - and turning it on sets a password first and
  then asks Windows for the firewall rule. The installer no longer creates
  that rule on its own.
• Settings › Signed-in devices: every browser that may use replaycut, with
  its name, address and when it was last seen, one "Sign out" per device
  and "Sign out everywhere".
• Diagnostics: three new lines - where the service listens (a failure when
  it is open to the network without a password), whether the firewall rule
  exists, and how the device login is doing.
• Sign in on your phone without typing the password. The login page
  offers "Ask" plus the name of your PC: the PC shows a notification, the
  open UI a card and the tray an entry, all with the same four-character
  code and with the device's name and address. One click on Allow and the
  phone is in. A request runs out after two minutes.
• The QR code in the wizard and in the settings signs a phone in when it
  is scanned: its address carries a token that is good once and for two
  minutes. Only this PC and signed-in devices get such a code.
• requireLoginOnLoopback in the settings: ask for the password on this PC
  as well, for a Windows account other people use.
• "Generate one for me" next to the password fields in the wizard and in
  the settings: four words from a built-in list, shown once in clear text.
• allowedHosts in the settings: names this replaycut answers to besides
  localhost, its own name and any address - for an own DNS name or a
  reverse proxy.

Changed

• An installation that is reachable from the network without a password
  keeps working, but says so: a red banner with "Set a password" and "This
  PC only", one notification per start, and a failure in the diagnostics.
• A request that names a host this replaycut does not answer to is refused
  with 421. That closes DNS rebinding, where a page in your browser uses
  its own name to reach the service on your PC.
• A password is 8 to 128 characters now, and there are no rules about
  digits or symbols: length is what counts.
• Signed-in devices are recorded with a name ("iPhone, Safari"), their
  browser, their address and when they were last seen. Sessions from
  earlier versions keep working.
• More than 30 failed logins from all addresses together within five
  minutes pause the password login for ten minutes.
• The size estimate in the share row learns from your own shares: the job
  records the recording's codec and bitrate (codec, sourceKbps), and
  the row uses the median ratio of the last plain H.264 shares of that
  codec instead of a fixed factor per codec.

Fixed

• The page is mobile-friendly again: 2.7.0 shipped with a broken viewport
  meta tag, so phones rendered the desktop layout scaled down.

• The "Limits" fields on the storage cards save from the settings page
  again; 2.7.0 sent the height as text and the service answered 400.

• A restart (update, settings, replaycut stop) no longer waits up to 5 s
  while a browser has the player open on a long clip: the shutdown now
  gives open connections one second, which is all the restarting request
  needs.

• "Post to ..." shows its result on the result card as well: the status
  reaches last (what the card shows after a reload), the card re-renders
  after the click, and a status such as "Discord: Link posted" or "Posted
  (HTTP 200)" is no longer drawn as a failure.

v2.7.0

[2.7.0] - 2026-09-06

Quality first: a share now looks like the recording, on every target,
and space limits belong to the target that needs them. Posting to Discord
and friends happens for the quick share only; everything else asks.

Changed

• Shares keep the recording's resolution and frame rate and are encoded in
  the encoder's quality mode: no more 1080p and 6000 kbit/s by default,
  the size follows the picture. The global "Video bitrate" setting
  (shareKbps) is gone; every storage card has an optional "Limits"
  section (max height, max bitrate) for the places where space matters.
  A "Publish to" onto a target with limits cuts the clip again within
  them.
• Only the quick share (the Share button's target) posts to Discord,
  Telegram and webhooks automatically; shares from the menu and "Publish
  to" stay quiet, and the result card and the history offer "Post to ..."
  instead (POST /api/jobs/<id>/post).
• The share mode "Fast copy" is now called "As recorded (no re-encode)".
• The Share menu says which target posts automatically, the progress card
  shows "no auto-post" for the others, and the size estimate accounts for
  the recording's codec (an AV1 recording grows about 2.5x as H.264).

Fixed

• The stage list under the progress bar broke its layout as soon as a
  stage was done: the wizard's "done" page style leaked into it.

v2.6.1

[2.6.1] - 2026-09-06

Fixed

• "Publish to ..." on a history entry from before the last restart answered
  "unknown job"; the source is now read from the history as well.

Changed

• docs/privacy.md states what replaycut stores and sends, and
  docs/youtube.md names the home page and privacy URLs Google wants
  before an app can be published.

v2.6.0

[2.6.0] - 2026-09-06

Beyond the cloud folder: a share can become a YouTube video (a vertical cut
a Short) or a post on X, the link can go to Telegram or any webhook next
to Discord, the finished file downloads straight to the phone, and a
browser that cannot play the recording gets a playable copy on demand.

Added

• YouTube as a share target: every share is uploaded as its own video
  (unlisted by default, private or public by choice), title from the clip,
  description from a template, link youtu.be/<id>. Uses your own Google
  client because of YouTube's upload quota; connected with a code at Google
  like OneDrive, or, with a Desktop client, in the browser on this PC
  (loopback login with PKCE: POST /api/oauth/<provider>/loopback,
  GET /oauth/<provider>/callback). docs/youtube.md walks through the
  five-minute setup.
• X as a share target: every share becomes a post with the video attached
  (chunked media upload, text from a template), link x.com/<user>/status/ <id>; connected in the browser on this PC. Needs a build with the
  replaycut app's client id.
• Telegram as a notify integration: a bot posts the link into a chat,
  group or channel (integrations.telegram, token as telegramToken,
  POST /api/test/telegram).
• Generic webhook as a notify integration: a JSON POST per share to any
  URL, signed with X-Replaycut-Signature when a secret is stored, for
  n8n, Home Assistant, Zapier or a Matrix bridge (integrations.webhook,
  POST /api/test/webhook).
• Download: the result card and the history offer the finished MP4 as a
  download (GET /api/jobs/<id>/file); on a phone it lands in the gallery,
  ready for TikTok, Instagram or WhatsApp.
• Playable preview: when the browser cannot decode the recording (AV1 on
  an iPhone), the player offers "Make a playable preview", a 720p H.264
  copy made on the PC and kept next to the preview (clip.previewH264,
  POST /api/clips/<base>/preview). previewH264: always in the settings
  makes it right after every recording with idle priority.
• Vertical cut: "Vertical 9:16 (Short)" in the share row crops a full-height
  window (position by slider, shown over the player) and scales it to
  1080x1920 - a Short on YouTube, or a file for TikTok, Reels and WhatsApp
  (vertical and verticalPos in POST /api/share and the job).

Changed

• The Integrations tab lists YouTube and X under Storage, Telegram and
  Webhook under Notify; the OneDrive and YouTube cards share one connect
  flow. The delete dialog's "also remove" now names every storage, not
  only Nextcloud.
• Notify integrations receive the share as structured data (title, clip,
  target, link, time); the Discord post itself is unchanged.

v2.5.0

[2.5.0] - 2026-09-05

Share where you like: every configured storage is a target with its own
entry in the Share menu, a finished clip can be published to another one,
and three new storages join Nextcloud - OneDrive (connected with a code at
Microsoft), any S3-compatible bucket and any WebDAV server.

Added

• Share targets: every configured storage is a target, POST /api/share
  takes target (a storage id or file), the default is the storage marked
  "quick share" in the settings. config.targets lists the integrations
  with their state.
• Publish again: POST /api/jobs/<id>/publish sends the finished file of a
  share to another storage without cutting it again.
• OneDrive as a storage: connect with a code at Microsoft (device flow, works
  from a phone), uploads go to Apps/replaycut/<month>/ with a link anyone
  can open. GET /api/oauth/<provider>, POST .../start, POST .../disconnect. Needs a build with a client id.
• S3-compatible storage (AWS S3, Cloudflare R2, Backblaze B2, MinIO, Wasabi):
  SigV4-signed uploads to <prefix>/<month>/, links from a public URL or
  presigned with an expiry; POST /api/test/s3 checks bucket and keys.
• Generic WebDAV storage: any DAV server plus a public URL that serves the
  folder; POST /api/test/webdav checks server and login.
• Deleting a clip with "also remove from storage" now removes the remote
  copies from every storage its shares went to.

Changed

• The post stage of a job is called notify (was discord); the status
  text stays in discord. Settings gain integrations.nextcloud.quickShare
  and integrations.discord.autoPost, both default on.
• Integrations tab in two groups, Storage and Notify, with "Quick share
  target" and "Post automatically" switches; the Share button gets a menu
  with the other storages and "file only"; result card and history show the
  target and offer "Publish to ..." for every other storage.

v2.4.0

[2.4.0] - 2026-09-05

Cutting gets comfortable: shares queue up and can be cancelled, every clip
has a picture, the Nextcloud quota sits in the header, a fast copy mode
skips the re-encode, the GPU decodes where it can, and the page hears about
changes the moment they happen.

Added

• Shares queue up instead of answering "a share is already running": the
  Share button stays usable, the card shows the place in the queue, and the
  next job starts as soon as the running one ends (position in the
  answer and the job, queue in GET /api/clips).
• Cancel a share: POST /api/jobs/<id>/cancel and the Cancel button on the
  progress card. Waiting jobs leave the queue at once; a running encode or
  upload is stopped and its partial output removed.
• Thumbnails: every clip shows a picture from 10 s before its end in the
  list and as the player poster (thumb on the clip, GET /media/<base>.jpg).
• The Nextcloud quota in the header ("Nextcloud 63 %", yellow from 80 %,
  red from 95 %), refreshed in the background (config.quota).
• Fast copy: a share mode that keeps the OBS video stream instead of
  re-encoding (keyframe-accurate, mode: copy, actualStart in the job).
  The choice is remembered in the browser; the default stays H.264.
• GPU decoding: the encoder detection now tries the full GPU path of each
  vendor with a real clip (AMD d3d11va, NVIDIA cuda with scale_cuda,
  Intel qsv) and falls back to software decoding per share when it fails.
  On an AMD card the AV1 decode moves off the CPU (13 s instead of 42 s CPU
  time for 30 s of 1440p60). hwaccel gains auto (the default) and none.
• replaycut bench: encodes part of the newest clip with every profile and
  prints wall time, CPU time and speed.
• The page listens to GET /api/events (Server-Sent Events) instead of
  asking every 3 s: changes show up at once, an idle page costs nothing,
  and a restart no longer waits for open connections. Polling stays as the
  fallback.
• The title field suggests the recording day and time as a placeholder;
  Enter on the empty field takes it.
• A keyboard shortcut list behind the "?" button and the "?" key.

Changed

• Contract: a second POST /api/share while a job runs answers 202 with a
  queue position (409 only for the same cut twice).

Fixed

• "Update now" on a release that has no signature yet ends in an error
  ("not signed yet") instead of waiting forever.

v2.3.1

[2.3.1] - 2026-09-05

A small release to prove the one-click update from 2.3.0.

Fixed

• README and CHANGELOG: the install path %LOCALAPPDATA%\replaycut\app had
  lost its backslashes.