UPCOMING.md: gap list, techy's take, agreed direction (MariaDB metadata, markers, future watch app)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
@@ -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):
|
||||
|
||||
|
||||
95
UPCOMING.md
Normal file
95
UPCOMING.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user