From 2078a5341970dba210ff11b2173e041bd3533e42 Mon Sep 17 00:00:00 2001 From: Brandyn / Techy Date: Sun, 1 Nov 2026 18:21:38 -0600 Subject: [PATCH] UPCOMING.md: gap list, techy's take, agreed direction (MariaDB metadata, markers, future watch app) Co-Authored-By: Claude Fable 5.1 --- README.md | 1 + UPCOMING.md | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 UPCOMING.md diff --git a/README.md b/README.md index 00fc8a9..d8b422f 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,7 @@ > **FRESH-INSTALL.md** = the ordered walkthrough from an empty box to a working stack and pipeline, manual steps included. > **HOSTNAME-CHANGE.md** = every place a hostname lives and how to rename a subdomain or move to a new base domain safely. +> **UPCOMING.md** = what is still missing for a mil-sim community (gap list, techy's take, agreed direction: metadata DB, markers, watch app). **Hostnames** (all CNAMEs to the main host; one Discord login covers all of them): diff --git a/UPCOMING.md b/UPCOMING.md new file mode 100644 index 0000000..6e84fd9 --- /dev/null +++ b/UPCOMING.md @@ -0,0 +1,95 @@ +# Upcoming — what a mil-sim community media stack still needs + +Written 2026-11-01 from a conversation between techy and Claude. Three parts: the gap list as first drafted, techy's +take on it, and the agreed direction. Living plan lives in `CommunityDiscordMedia.md`; current state in `STATUS.md`. + +## 1. The gap list (first draft) + +Measured against what mil-sim groups actually do with footage, the stack covers capture, storage, access and live +viewing. The gaps cluster around the debrief workflow, moments, comms audio, and keeping the box healthy. + +### Debrief and review (the core mil-sim use) +- **Synced multi-POV playback.** The timecode track makes it possible, but nothing plays it yet. A VOD mode of the + live portal that opens every recording from one night and scrubs them in lockstep turns the archive into an + after-action-review tool. The single biggest missing piece. +- **Ops as a first-class object.** Titles are free text today. An op/training event that groups every streamer's + recording, that night's clips, briefing files and finals → collections, per-op download bundle for editors, a + Discord thread per op; the dock offers tonight's event instead of a typed title. +- **Markers.** A "mark this" button in the dock, a Discord command, or an emoji reaction during the live post stamps + the server clock into metadata → chapters, editor markers, the shortlist for the review session. Cheap: the clock + already exists. +- **Twitch-style clips from the live recording.** Segments are on disk while someone streams, so a `!clip` of the + last 30–60 s is a server-side cut with no streamer action. + +### Audio +- **Separate comms track.** Editors cutting to radio chatter want game audio and voice on separate tracks. RTMP + carries one; SRT can carry several and OBS can send multiple audio tracks over it. +- **Voice server recording.** Some units record TeamSpeak/Mumble as the authoritative comms log. Consent question + before a technical one. + +### Standardisation +- **OBS starter kit.** Downloadable scene collection + profile with the band, B-frames 0, bitrate caps, dock URL. +- **Callsign tags.** The rename feature is per viewer; a server-side label ("1-1 Lead") on live panels and recordings. +- **Non-video intake.** Briefing slides, map images, after-action notes have no drop point (clip intake is video only + by design). + +### Health and operations +- **Disk monitoring and alerts.** Nothing warns when disks fill, when the sweep writes a failure log, or when a + stream drops. With hours of 1440p a night this is the most likely quiet death. Discord alert = small job. +- **Archive tier.** The home archive puller is planned, not built; the 15-day hot window is the only window. +- **Backups.** Authentik and Gitea databases are not dumped anywhere yet. + +### Audience +- **Public showcase.** Everything is gated; recruitment needs a route for finals to go public (YouTube from finals). +- **Mobile.** Jellyfin apps work; the live portal is desktop-only in practice. + +Suggested top three: alerts (protect everything else), markers (cheap, feed everything downstream), synced +multi-POV playback (what the archive is actually for). + +## 2. techy's take + +- **Synced multi-POV playback — yes.** It means more metadata tracking, and we already have too many files: put the + metadata in a database (Postgres or MariaDB), not more sidecars. +- **Ops come with the Discord bot.** It has roll calls; we are waiting on the bot, its website and its database. +- **Markers — good.** Likely just in the live window for now. +- **Live clips — nice idea, but** we may instead build something like the live page for *watching*: multi-POV playback + plus single-POV playback plus search, and replace Jellyfin entirely (it is only a half-baked fit). Decision for later. +- **Separate comms is coming-ish.** We run mixed comms: once the bot exists it will listen to a voice channel after + roll call. The Go Live button already excludes system audio, so it will carry game audio only. We also use in-game + comms, so it will never be perfect. + +## 3. Agreed direction (Claude's reply) + +Everything lines up on one axis: **the server clock**. Recordings, markers, roll calls and comms audio are all stored +as UTC instants and joined later, which is exactly what a synced player needs. + +**Database.** Use the MariaDB that already runs for the bot rather than adding Postgres: one database to back up, and +the bot's ops/roll-call tables land beside ours, so "this op → these recordings" is a query, not a convention. Keep the +per-file sidecar as the self-describing fallback; the sweep writes both; a reconcile command rebuilds the tables from +sidecars if the database is ever lost. Rough shape: + +| table | holds | owner | +|---|---|---| +| `recordings` | path, streamer, title, start UTC (band or arrival), duration, fps, timecode source + drift, band removed, gaps, optional op id | sweep | +| `markers` | UTC instant, author, stream path or null (= everyone), kind, note — stored by **time, not file offset**, so a marker placed live attaches to the recording when published and to every other POV of that moment for free | dumpd (portal), later the bot | +| `clips` | file, owner, arrival time, converted or not | sweep / dumpd | +| `ops`, `roll_call` | the bot's; we only read them | bot | + +**Markers in the live window.** A Mark button on the focused panel plus a hotkey, posting the current server time and +the stream path to dumpd. Small, and it gives the future player its chapter list from day one. The Discord-command +version comes with the bot and writes to the same table. + +**Replacing Jellyfin.** The database makes it a clean later decision. A watch app built on the portal's code does +single POV with search by op, streamer, date and marker, and multi-POV with lockstep scrubbing driven by the timecode. +Until then Jellyfin keeps reading sidecars and nothing breaks. + +**Comms.** Bot-captured Discord audio after roll call, stamped on receipt by the same box, lines up with everything +else with no extra sync work. In-game comms stay in the game audio; fine for review. + +**Sequence.** +1. Schema + sweep inserts + marker endpoint + Mark button in the live portal (small; everything else reads from it). +2. Write the table contract into the bot developer's brief (`bot/AGENT.md`) so the bot is designed against it now. +3. Watch app (single + multi-POV + search) once the bot's ops data exists and the Jellyfin decision is made. + +Not scheduled, still true: alerts (disk / sweep failures / dropped streams), backups of Authentik + Gitea databases, +archive puller, OBS starter kit, callsign tags, non-video intake, public showcase, mobile.