Main roadmap
From research copy to controlled 24/7 operation
Every stage is deliberately gated. Nothing reaches the on-air path until it has been tested, verified, and assigned a clear rollback.
Complete
Current boundary
Not yet activated
24/7 channel automation project
Build a dependable playout operation that Hermes can prepare, monitor, and safely supervise.
The goal is not to replace ATHENSA’s frame-accurate broadcast engine. Hermes becomes the operational intelligence above it: preparing schedules, validating content, monitoring logs, coordinating recovery, and involving a human when a decision carries real broadcast risk.
Verified from the copied installation
The exact software generation
Static PE metadata and bundled ReadMe files agree. No ATHENSA executable was launched during research.
7.0.0.1257
21 April 2017Offline playlist and schedule preparation. Supports 4K, HEVC/H.265, and AJA Corvid hardware profiles.
7.0.0.1257
21 April 2017Internally identified as AirBox. Handles timed playout, recovery, logs, external events, RTMP, and output modules.
7.0.4.155
15 May 2017Playout-safe media replication and metadata transfer. Its operational limitations directly shape our storage design.
7.0.0.959
2 February 2017Internally identified as TitleBox. Provides templates, dynamic data, API events, NetControl, tasks, and As-Run logs.
Operating model
Intelligence above, deterministic broadcast below
The safest architecture gives each layer one clear job. Hermes plans and supervises; ATHENSA owns frame-accurate execution.
Hermes control plane
Reason and supervise- Inventory media and maintain metadata
- Construct and preflight schedules
- Monitor processes, ports, storage, and logs
- Compare expected versus actual playout
- Report, alert, and request approval
- Coordinate—never duplicate—recovery actions
ATHENSA media plane
Execute preciselyListPlaylist preparation, imports, validation
PlayoutAirBox timing, output, recovery, logs
SafeBoxControlled media replication and transfer
GraphicsTitleBox templates, data, rendering, API events
- Own frame-accurate timing and on-air state
- Run local watchdog restart or bypass behavior
- Produce authoritative System and As-Run logs
What we learned
Discoveries that changed the plan
These are the findings that materially affect how Hermes should interact with the channel.
Playlist path
Use ListBox imports before attempting native playlist generation
ATHENSA supports tab-delimited, CSV, and fixed-width traffic imports with reusable column mappings. Native .ply construction depends on a separate AirBox SDK that was not included. Our first MVP will let ListBox create the final playlist.
Daily schedule
Daily playlists have a deterministic filename contract
Scheduled playlists follow YYYY_MM_DD_HH_MM_SS.ply. Playout can load them automatically and catch up using the playlist start time and current system time after restart.
Watchdog
Playout already includes restart and bypass mechanisms
The copied installation contains watchdog dialog, relay, and restart plug-ins plus RestartModule.exe. Hermes must verify these actions rather than firing a competing restart.
Monitoring
System and As-Run logs are the safest source of truth
Playout produces mandatory System logs and optional tab-delimited As-Run logs. Graphics has per-instance As-Run logging. Hermes can reconcile planned versus actual output without continuously scraping the GUI.
SafeBox
Mapped drives cannot be used as production SafeBox sources
The bundled SafeBox notes explicitly prohibit mapped HDD source folders. The shared Z: folder is research-only; production storage must use an approved local or tested UNC arrangement.
Performance
Copying and startup can disturb playout
High-speed content copying may cause storage hiccups, and SafeBox startup is resource-intensive on a shared host. Transfer operations and restarts must be isolated or carefully scheduled.
Graphics
TitleBox exposes narrow integration surfaces
Graphics supports NetControl ports, matching channel IDs, API events such as EVENT 1001, Windows Named Events, FileLink, XML, RSS, HTML, ODBC, tasks, and scripts. We will prefer constrained data/network bridges over letting Graphics launch arbitrary automation.
Evidence
A historical Graphics freeze confirms monitoring is essential
The copied folder contains a 2020 freeze report for ATHENSA Graphics. It does not prove a root cause, but it confirms that graphics health, bypass behavior, and recovery verification belong in the design.
Completed technical subgoal
PLY, SDK, protocol, and MCP feasibility test
Six consecutive real ATHENSA playlists were analyzed without running the copied software. The file-level integration is now proven; vendor acceptance and undocumented network control remain explicit live gates.
Not present
Vendor package still requiredNo SDK/API directory, headers, import libraries, IDL/TLB, or SDK manual exists in the copied installation.
6 files
1,155 media rowsEvery file parsed cleanly, every duration is within one second of 24 hours, and all 516 unique media paths resolve.
4 tools
Protocol smoke-testedList, inspect, validate, and atomically stage allowlisted playlists with hash, media, timing, and post-write verification.
Pending
Requires runnable licensed ATHENSAThe research-only copy cannot prove that ListBox/AirBox opens or reloads the generated candidate. That remains the next controlled gate.
Proven offline path
Implemented- Hermes calls the local ATHENSA PLY MCP server
- MCP validates syntax, IDs, duration, encoding, metadata, media existence, and SHA-256
- The validated file is written to an allowlisted staging folder using temporary write, fsync, and atomic rename
Next acceptance path
Not yet claimed- Open the existing production `.ply` in a licensed offline ListBox
- Open the reconstructed candidate and compare 192 items, metadata, and 86,400.28767-second duration
- Only after acceptance, test a controlled daily-folder load/reload in AirBox
Protocol conclusion: Net Sender is verified UDP and UMP uses UDP broadcast. Playout and TitleBox Net Control binaries contain both TCP and UDP networking code, but the exact command transport/framing is not documented. No protocol named “TCP-8B” was found, so we will not guess an endpoint.
New operational baseline
Planner, full-day slots, and filler boundaries
The Telecasting Planner now provides the fixed program skeleton. Recent playlists provide program names through NOW metadata and show how actual start times drift slightly as fillers absorb real media duration.
5-minute grid
30 / 60 / 90-minute allocationsDates run across columns, time runs down rows, and merged-cell height defines intended slot length.
40 program rows
Program names, not episode IDsThe latest valid reference maps the entire day from AWAKENING WITH BRAHMA KUMARIS at 00:00 through JEWELS OF KNOWLEDGE at 23:00.
13:00 & 22:00
Reference-day planner placeholdersThese blocks are available for filler construction; the planner does not specify the actual filler assets.
Still evolving
Operator guidance requiredFiller priority, weekday meditation themes, Murli Saar placement, bumper order, substitutions, and formal timing tolerance remain open.
Authority rule: the planner defines intended fixed slots; approved substitutions and special-day changes must be explicit; fillers are constructed only after scheduled programs are resolved.
Open the living playlist rules Open the program-name slot table
First automation deliverable
The playlist MVP
This is the lowest-risk path from an editorial schedule to an ATHENSA daily playlist.
Inventory
Scan approved content and record paths, duration, codec, aspect, audio, and metadata.
Construct
Build the schedule with timing, categories, fixed events, graphics metadata, and fallback rules.
Preflight
Reject missing files, unsupported formats, overlaps, gaps, zero duration, and invalid dates.
Import
Write a delimited traffic file and process it through a verified ListBox import mapping.
Verify
Inspect the resulting playlist independently and compare duration and item order to the plan.
Promote
Move the approved file atomically from staging into the daily-playlist folder.
Non-negotiable boundaries
Safety rules for the on-air system
Every integration begins in a copied offline environment and enters production only through staged approval.
.ply yetCandidate generation and file-layer staging are proven offline, but real ListBox/AirBox acceptance is still required before production use.
The research share may remain on Z:; a production SafeBox source may not.
SafeBox deletion stays disabled until dry runs, scope guards, backups, and explicit approval are proven.
ATHENSA watchdog, Windows startup, and Hermes escalation must never issue conflicting restarts.
Schedule updates touch only future content and are validated before promotion.
A known-good fallback must remain independent of daily schedule generation.
Deleting content, changing output, going live, or bypassing safeguards requires explicit authorization.
Current boundary
What happens next
The planner skeleton, program-name slots, PLY grammar, and file-layer staging path are mapped. The next work converts the operator’s evolving filler practice into explicit testable rules, then proves the result in licensed ATHENSA.
Project evidence
Files and research locations
Research-only ATHENSA copy
Private internal network share — path redacted for public hosting
- Never modified during research
- No vendor executable, BAT, CMD, or VBS was run
- Contains List, SafeBox, Playout, Graphics, examples, notes, and help
Hermes research pack
Local Hermes project folder — path redacted for public hosting
- Public manuals and exact-build analysis
- Machine-readable inventory and static findings
- Decompiled local AirBox, TitleBox, and Clip Trimmer help
- Flattened searchable help corpora