Media-Server-Setup/UPCOMING.md

# 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.