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.