The complete project chat

Yes — that’s a strong use case for Hermes. The goal would be to make Hermes the operations manager for the entire 24/7 channel, while Athensa handles the actual playout/broadcast work.

Hermes could eventually manage:

• Building and updating daily playlists
• Importing videos into Athensa
• Scheduling programs, promos, ads, and station IDs
• Checking for missing, corrupt, or incorrectly formatted media
• Starting and monitoring the channel
• Detecting frozen playback, black screens, silence, or application crashes
• Restarting Athensa or switching to emergency backup content
• Monitoring disk space, internet, CPU, and stream health
• Producing daily broadcast reports and error logs
• Sending alerts to Telegram when human attention is genuinely needed
• Preparing upcoming content automatically
• Maintaining fallback playlists so the channel doesn’t go blank
• Potentially managing YouTube or other streaming destinations too

For reliability, I’d design it in layers:

1. Athensa — playout engine
2. Hermes automation scripts — deterministic control and monitoring
3. Hermes Agent — planning, decision-making, recovery, reporting
4. Windows startup/watchdog — keeps everything running after crashes or reboots
5. Telegram control — commands like status, start, stop, reschedule, emergency mode
6. Human approval rules — publishing or deleting important material still requires confirmation

The important principle is: Hermes shouldn’t repeatedly click through the interface for every routine operation if Athensa offers an API, database, watched folder, command-line interface, or scheduling-file format. We’ll use the most reliable integration available and reserve visual Computer Use for tasks that cannot be automated directly.

One tiny correction, unless your channel has discovered three bonus hours hidden behind the sofa: you probably mean 24/7. 😄

Please send me the official Athensa website/download link, exact product name, or a screenshot of the software. “Athensa” isn’t specific enough for me to safely identify the correct application, and its available integration methods will determine the architecture. Once I have that, I can inspect it and build a proper automation roadmap around your actual setup.

I’ve now gone through both websites and the linked ATHENSA product PDF. The first URL currently redirects to the broader ATHENSA/PlayBox page.[1]

What’s especially promising for Hermes

ATHENSA isn’t just one playout application—it’s a modular broadcast ecosystem:

• AirBox / ATHENSA Playout: unattended playlist playout
• TitleBox / ATHENSA Graphics: logos, crawls, clocks, templates, and dynamic graphics
• CaptureBox / ATHENSA Ingest: scheduled recording and multi-source capture
• ListBox: standalone playlist editor and scheduler
• DataBox: SQL-based media asset and metadata management
• SafeBox / Transfer: automated file transfer, replication, delivery, and removal
• QCBox: media verification, including black frames, frozen frames, continuity, duration, and loudness checks
• Backup Manager: automatic 1:1 or N:M redundancy
• Universal Matrix Controller and IP Switch: routing and failover control.[1][2][3]

The playout system already supports automatic playlist loading, unattended 24/7 operation, live-source pass-through, playlist modification during broadcast, external equipment control, and commercial triggers such as GPI, DTMF, and SCTE-35.[2]

The biggest integration opportunity is the graphics system. ATHENSA says its graphics engine can:

• Run in the background without the front-end interface
• Receive script commands from third-party software through a network protocol
• Be controlled through AirBox playlist events
• Trigger graphics according to playlist metadata
• Populate text objects from metadata
• Consume external RSS, HTML, and XML data.[2]

The older product document also explicitly mentions TitleBox Net Control, remote control of TitleBox, third-party automation through a TitleBox API, playlist conversion, VDCP control, router control, and SQL-based DataBox media management.[3]

Preliminary Hermes architecture

Based on this information, we should avoid making Hermes “visually click everything.” The more reliable arrangement will likely be:

1. Direct network/API control for TitleBox and compatible modules
2. Playlist-file generation and validation for AirBox/ListBox
3. Database or export-based integration with DataBox
4. Watched-folder workflows for SafeBox and content delivery
5. Log/process monitoring for playout health
6. Computer Use only as a fallback for functions without an exposed interface
7. Telegram dashboard and alerts through Hermes
8. Independent watchdog scripts so essential recovery still works even if the reasoning agent is temporarily unavailable

What I’ll look for in your documents

When you send them, I’ll specifically extract:

• AirBox playlist formats and file extensions
• TitleBox API and Net Control commands
• IP addresses, ports, and protocol details
• Scheduling and metadata formats
• DataBox database/export interfaces
• SafeBox watched-folder and transfer rules
• Log locations and meaningful error messages
• Command-line options and Windows service behavior
• Start, stop, restart, and crash-recovery procedures
• Backup and failover controls
• Supported remote-control protocols
• Licensing limitations that affect automation
• Any version-specific differences

This is looking genuinely workable. ATHENSA already contains many of the deterministic broadcast mechanisms; Hermes can become the intelligent operations layer above them—planning, preparing, checking, monitoring, recovering, and contacting you only when the machine has encountered something it shouldn’t decide alone.

Send the documents whenever you’re ready. I’ll connect their technical details with what I’ve learned here rather than treating them as isolated files.

Sources

[1] https://www.athensa.tv/channel-in-a-box — ATHENSA / Playbox — Channel-in-a-Box
[2] https://vertexmediatechnology.com/athensa — ATHENSA overview — Vertex Media Technology
[3] Open bundled PDF — ATHENSA End-user Price List (December 2022)

I’ve extracted and reviewed the manual successfully. It contains about 353 PDF pages of material and covers AirBox, ListBox, CaptureBox, TitleBox, Clip Trimmer, Live Viewer, GPI, scripting, scheduling, logging, and AirBox–TitleBox integration.

Important version warning

This is Channel in a Box User Manual v1.6 from December 2015, covering:

• AirBox 4.2
• ListBox 4.2
• CaptureBox 2.9
• TitleBox 4.1
• Trimmer Server 1.0
• Live Viewer 1.0

It’s extremely valuable for understanding the system’s architecture, but we’ll need to compare it with the version you actually install. Some paths, ports, commands, file formats, and interface behavior may have changed.

What the manual confirms

1. Hermes can prepare the broadcast schedule

AirBox supports:

• Ordinary .ply playlists
• Automatically loaded daily playlists
• Tab-delimited and comma-separated playlist imports
• Playlist creation by third-party applications
• Playlist reloading when another application changes the file
• Metadata, fixed-time events, bookmarks, graphics events, live inputs, transitions, and external-control events

Daily playlists use filenames in this format:

YYYY_MM_DD_HH_MM_SS.ply

For example:

2026_08_21_06_00_00.ply

This gives us a practical initial workflow:

1. Hermes builds tomorrow’s schedule.
2. Hermes validates every media path, duration, codec, and metadata field.
3. Hermes produces an importable tab-delimited playlist.
4. ListBox/AirBox converts or saves it as the appropriate daily .ply.
5. Hermes places it into the configured daily-playlist folder.
6. AirBox automatically loads it at the scheduled time.

Direct .ply generation is also possible, but the manual says its precise format is documented separately in the AirBox SDK. We shouldn’t invent that structure.

2. AirBox already has useful recovery mechanisms

AirBox can:

• Launch automatically with Windows
• Start after a configurable hardware-initialization delay
• Start minimized
• Load the last playlist automatically
• Resume the previous playback state
• Resume the last-played item
• Resume from the previous position within a clip
• Catch up with the schedule after abnormal termination
• Reload a playlist when its file changes
• Fill gaps with fallback clips or auto-fill categories
• Use previous daily playlists when the current schedule is missing

In daily-playlist mode, AirBox attempts to calculate the appropriate insertion point from the playlist start time and the current system clock. That’s precisely what we need after a restart.

Hermes should supervise these mechanisms rather than replacing them. Real-time playout and frame-accurate timing must remain deterministic inside AirBox—not depend on an LLM thinking, “Hmm… which clip was next?” That would be broadcast roulette, and nobody needs that excitement.

3. Logs provide a strong monitoring interface

AirBox generates:

• System logs containing errors, events, and system activity
• Configurable As-Run logs
• Daily or per-playlist logs
• Metadata columns
• Simple tab-delimited text output
• Automatic log-retention management

TitleBox also has separate per-instance As-Run logs.

This means Hermes can monitor the channel without constantly looking at the interface. It can detect:

• Missing or unsupported media
• Playlist reloads
• Clips skipped during playout
• Start and stop events
• Application errors
• Schedule drift
• Unexpected gaps
• Missing As-Run activity
• TitleBox graphics failures

A watchdog can compare:

Expected playlist
        ↓
AirBox As-Run log
        ↓
Actual output history

If expected and actual behavior diverge, Hermes can alert you or execute an approved recovery procedure.

4. TitleBox is highly automatable

The manual confirms multiple automation paths.

Net Control

TitleBox listens for commands on a configurable NetControl Port and uses a Channel ID. AirBox can send commands to it after both sides are configured with matching values.

A TitleBox project must be exported as a .tmpl template and TitleBox must be placed in Net Control mode.

Commands can:

• Load templates
• Start or stop projects
• Clear the graphics buffer
• Reset graphics
• Play, stop, pause, or advance slides
• Start and stop individual objects
• Replace text
• Replace pictures, audio, or other media
• Update objects from playlist metadata

Graphic Rules

AirBox can automatically send TitleBox commands according to:

• Clip category
• Title
• Performer/star
• Custom metadata
• Clip position
• Percentage or millisecond offsets
• Upcoming playlist items
• Bookmarks
• Upcoming items of a particular category

For example, it can automatically generate:

• “Now Playing”
• “Coming Up Next”
• Program titles
• Speaker names
• Episode information
• Channel bugs and logos
• Promotional lower thirds
• Scheduled crawls
• Dynamic images associated with each program

The rule language supports structures like:

LOAD_TEMPLATE=TB_Music.tmpl
Title.text=%clip_title%
Star.text=%clip_star%

It can also reference upcoming items:

Next.text=%clip_title[+1]%

5. TitleBox has its own API and scripting system

TitleBox supports:

• Internal command scripts
• Program scripts using Pascal, C++, Visual Basic, or Java-like syntax
• Object, slide, project, data-provider, and storage classes
• Automatically executed scripts:
• OnProjectLoad
• OnProjectUnload
• OnProjectStart
• OnProjectStop
• API-triggered events using commands such as:

EVENT 1001

An API event can be connected to any task created in TitleBox’s Task Manager.

TitleBox can also execute external:

• .exe
• .bat
• .cmd

However, its internal program scripts are intentionally short-running: the manual says scripts taking more than roughly one or two seconds may be terminated. Therefore, complex reasoning and long processing should happen in Hermes—not inside a TitleBox script.

6. Graphics can receive external data

TitleBox supports data from:

• Text and RTF files
• ODBC databases
• XML
• RSS
• HTML tables
• Weather providers
• Emergency Alert System sources
• File links that update whenever the source file changes

A very safe integration method could be:

1. Hermes writes approved text or structured data to a watched file.
2. TitleBox reads that file.
3. The on-air object updates automatically.
4. TitleBox logs the action.

This could be ideal for announcements, quotes, schedules, messages, program descriptions, weather, or information-channel crawls.

7. CaptureBox can automate ingest

CaptureBox supports:

• Manual capture
• Automated single capture
• Batch capture
• Scheduled capture
• IP transport-stream capture
• RS-422 VTR control
• Channel switching
• Capture lists using .cap
• Schedule lists using .lst
• Daily, weekly, or other recurring capture schedules

Once a CaptureBox schedule is prepared and Armed, capturing starts automatically according to the schedule.

Hermes could eventually:

• Generate CaptureBox schedules
• Check destination disk space
• Verify whether expected files appeared
• Validate duration and file integrity
• Move completed media into the correct library
• Add it to future playlists
• Alert when capture failed or produced an incomplete file

8. External-device control is built in

AirBox supports playlist events for:

• UDP text messages through Net Sender
• GPI
• DTMF
• RS-232 and RS-422
• VTR control
• Matrix and router control
• TitleBox Net Control
• Various video switchers
• Network timecode transmission

The UDP Net Sender can send arbitrary text messages to a configured port when an event is reached. That gives us another deterministic bridge between AirBox and Hermes-controlled services.

Recommended division of responsibility

Three documents we still need most

This manual repeatedly points to separate technical documentation:

1. AirBox SDK documentation
   Needed for direct .ply generation and deeper third-party control.

2. TitleBox API User Manual
   Needed for exact network commands, API syntax, connection behavior, and full event control.

3. Manual matching the currently installed ATHENSA version
   Needed to confirm that the 2015 procedures still apply.

The current manual confirms the project is feasible. It also shows that we won’t need to depend entirely on GUI automation—there are playlist files, watched folders, logs, UDP communication, Net Control, API events, scripts, ODBC, and structured scheduling mechanisms. That’s a much healthier foundation for a 24/7 channel.

Send the remaining documents when ready. I’ll keep building one unified automation specification from all of them.

Yes — the splash screen gives us a much better identification of your actual installation.

Exact version identified

The screen says:

• Product: ListBox 7
• Version: 7.0
• Build: 1257
• Edition: PRO
• License: Permanent
• Hardware licensing: WIBU-BOX dongle detected
• Maintenance plan: Expired on 2021-02-03

The important distinction is that the permanent software license hasn’t expired. The expired date appears to refer to the maintenance/update entitlement. Your installed build should therefore continue operating, but installing a newer build may require renewed maintenance or an updated license. I would not upgrade this machine casually—broadcast software has a special talent for teaching humility five minutes before airtime.

I’ve omitted the WIBU-BOX serial from this reply and from my research notes because we don’t need to expose it for workflow design.

What I found

The exact phrase “ATHENSA ListBox 7.0 build 1257” doesn’t lead to a publicly indexed build-specific manual or release notes.

However, I found and downloaded several closely related manuals:

1. ATHENSA ListBox v4.2 manual, December 2015 — the immediate documented predecessor in the same ATHENSA product line.[1]
2. ListBox User Manual v2.3, March 2020 — covers the later ListBox Mega generation and includes extensive AirBox/ListBox workflow examples.[2]
3. AirBox User Manual, October 2019 — important because ListBox’s documentation repeatedly refers users to AirBox for shared playlist commands, events, imports, startup logic, and module configuration.[3]
4. AirBox User Manual v2.3, March 2020 — a more comprehensive manual covering playlists, events, settings, logging, startup recovery, graphic rules, Net Control, and external devices.[4]
5. Channel-in-a-Box User Manual v2.2, October 2019 — covers AirBox, ListBox, CaptureBox, TitleBox, integration, scheduling, scripting, and failover as one system.[5]
6. Historical ATHENSA distributor documentation placing AirBox 7 and TitleBox 7 in the June 2016 generation, which helps date and contextualize your v7 suite.[6][7]
7. Current ListBox product documentation covering traffic-system imports, trimming, playlist events, media compatibility, and live playlist updating.[8]

Research pack created

I saved everything into:

[Open the research pack index](assets/documents/research-pack-readme.md)

It contains:

README.md
manuals\
  Athensa_Channel_in_a_Box_User_Manual_v1.6_2015.pdf
  ListBox_User_Manual_Athensa_2015.pdf
  ListBox_User_Manual_2020.pdf
  AirBox_User_Manual_2019.pdf
  AirBox_User_Manual_2021.pdf
  Channel_in_a_Box_PlayBox.pdf

The README.md contains:

• Exact version identification
• Documentation compatibility hierarchy
• Relevant automation capabilities
• Proposed Hermes integration paths
• Broadcast-safety rules
• Missing documentation we still need
• Source URLs

Open the research pack index

What this confirms about your ListBox version

ListBox is primarily the offline playlist and schedule preparation component. It can be used to:

• Create ordinary and daily playlists
• Add media, live sources, and timed events
• Insert stops, waits, fixed-time events, logos, GPI events, switcher commands, and TitleBox events
• Validate media according to the selected AirBox output module
• Import traffic schedules from:
• Tab-delimited files
• CSV files
• Fixed-width text files
• Carry metadata used by TitleBox graphic rules
• Export CaptureBox lists for missing media
• Preview and trim clips
• Prepare playlists while AirBox remains on air
• Save date-and-time-named daily playlists
• Modify future schedule items without changing the currently playing item

That makes ListBox one of the best entry points for Hermes. Hermes can prepare and validate schedules without directly interfering with the real-time playout engine.

Safest initial Hermes workflow

I recommend beginning with this deterministic pipeline:

Content folders
      ↓
Hermes media inventory
      ↓
Codec/path/duration/metadata validation
      ↓
Schedule construction
      ↓
Tab-delimited or CSV traffic file
      ↓
ListBox import template
      ↓
ListBox playlist validation
      ↓
Daily .ply playlist
      ↓
Staging verification
      ↓
AirBox daily-playlist folder

This avoids reverse-engineering .ply files before we have the SDK. It also allows us to compare Hermes’ generated schedule with what ListBox actually accepts.

Exact-version information still needed

The manuals repeatedly refer to separate technical material that isn’t publicly indexed:

• AirBox SDK
• TitleBox API User Manual
• Exact ATHENSA v7 release notes
• ListBox 7 build 1257 local help
• Precise .ply specification
• Import-template file format
• Command-line arguments
• Remote-control protocol details

The best source for these may already be inside the installed software directory. When we inspect the real installation, I’ll look for:

*.chm
*.hlp
*.pdf
settings.ini
*.ply
*.xml
*.dat
*.log
SDK\
API\
Help\
Manuals\
Samples\
Templates\

I’ll also inspect the executable’s file-version information, installed paths, file associations, sample playlists, and the application’s own Help menu. That local inspection will tell us which parts of the older manuals are still accurate for build 1257.

Most importantly: we have enough information now to design the system, but I won’t pretend the publicly available manuals are an exact build match. For production automation, we’ll validate every command and file format against your installed v7 software before letting Hermes touch an on-air schedule.

Sources

[1] Open bundled PDF — ATHENSA ListBox User Manual v1.2 (2015)
[2] Open bundled PDF — ListBox User Manual v2.3 (March 2020)
[3] Open bundled PDF — AirBox User Manual (October 2019)
[4] Open bundled PDF — AirBox User Manual v2.3 (March 2020)
[5] Open bundled PDF — Channel in a Box User Manual v2.2 (October 2019)
[6] https://widenetworks.net/Faq_quare/athensa-airbox — ATHENSA AirBox FAQ
[7] https://widenetworks.net/Faq_quare/athensa-titlebox — ATHENSA TitleBox FAQ
[8] https://playboxtechnology.com/scheduling-and-playlists — ListBox Scheduling and Playlist Creation

Absolutely. I’ve saved this as a durable project fact:

Private research-only ATHENSA installation copy (network path redacted)

It’s the research-only copy containing:

• ATHENSA List
• SafeBox
• ATHENSA Playout
• ATHENSA Graphics

I treated everything under Z: as read-only. No ATHENSA executable, BAT, CMD, or VBS file was run, and nothing in the copied installation was modified.

Exact versions confirmed

Static inspection of the executable version resources and bundled ReadMe files revealed:

All four primary applications are 32-bit x86 Windows programs. The internal executable metadata also confirms:

• ATHENSA Playout is internally AirBox
• ATHENSA Graphics is internally TitleBox
• The copy precisely matches the ListBox splash screen you shared

The separate ATHENSA List executable and the List executable bundled inside ATHENSA Playout are byte-identical, including the same SHA-256. Their help and default graphics-rules files are also identical.

A beautiful little discovery: the exact local manuals were inside

The copied folders contain:

• ABhelp.chm
• TB_help.chm
• ClipTrimmer.chm

I copied and safely decompiled these help systems into searchable HTML—without launching ATHENSA.

They contain:

• 206 AirBox help topics
• 183 TitleBox help topics
• 16 Clip Trimmer topics

I also created flattened searchable text versions, so future questions can be answered against the exact installed generation instead of relying only on public manuals.

Most important operational discoveries

1. SafeBox must not use mapped drives as production sources

The SafeBox build notes explicitly say:

Mapped HDDs must not be used as source folders.

Therefore, this Z: folder is perfectly fine for our research copy, but a live SafeBox job should not use Z: as its source. We’ll use an approved local path or properly tested UNC arrangement for production.

SafeBox also warns that:

• An unavailable source slows other content operations.
• SafeBox startup is resource-intensive and can disturb playout on the same machine.
• When all files in a destination folder are processed for deletion, the folder itself may be deleted.

So deletion automation will begin disabled. Hermes won’t be casually tidying broadcast storage like an overenthusiastic housekeeper.

2. ATHENSA has a real built-in watchdog

ATHENSA Playout includes:

WatchDogDlgPlug.dll
WatchDogRelayPlugin.dll
WatchDogRestartPlug.dll
RestartModule.exe
WatchDogCommon.dll

The exact local help says the watchdog can:

1. Display a malfunction warning
2. Switch a physical bypass relay
3. Restart Playout/AirBox

Hermes must coordinate with this watchdog—not compete with it. Each failure type will have one clearly designated recovery owner.

3. Logs are the safest monitoring interface

Playout supports:

• Mandatory System logs
• Optional As-Run logs
• Daily or per-playlist logs
• Configurable fields and time formats
• Tab-delimited output

Graphics has its own per-instance As-Run logger.

That gives Hermes a stable, low-risk way to monitor:

• What actually played
• What was skipped
• Application errors
• Schedule drift
• Missing files
• Graphics activity
• Restarts and recovery

4. The first playlist integration path is now clear

The exact local AirBox help confirms:

• Third-party software can create schedules.
• Tab-delimited, CSV, and fixed-width imports are supported.
• Column-mapping templates can be created.
• Imports can be saved as daily playlists.
• Daily playlists follow:

YYYY_MM_DD_HH_MM_SS.ply

The native .ply format is documented separately in the unavailable AirBox SDK. No production .ply samples or SDK were present in the copied program folders.

Therefore, our safe first implementation will be:

Hermes schedule
    ↓
Validated tab-delimited/CSV traffic file
    ↓
ListBox import mapping
    ↓
ListBox-generated .ply
    ↓
Independent verification
    ↓
Atomic promotion to AirBox daily-playlist folder

5. Graphics has several strong integration surfaces

The exact TitleBox help confirms:

• Configurable NetControl port
• Matching AirBox/TitleBox channel IDs
• Third-party network commands
• API events such as EVENT 1001
• Windows Named Events
• FileLink data
• XML, RSS, HTML, weather, and ODBC providers
• Program scripts
• Per-instance As-Run logging

It can even launch EXE/BAT/CMD files, but I recommend we don’t use that as our primary architecture. We’ll keep Hermes outside the render engine and use narrowly scoped data/network bridges instead.

There’s also an old bugreport.txt showing an actual Graphics freeze after several hours of operation. It doesn’t prove the cause, but it confirms that Graphics health monitoring and recovery are essential—not optional decoration.

Research pack updated

Everything is organized under:

[Open the research pack index](assets/documents/research-pack-readme.md)

The main new report is:

LOCAL_COPY_ANALYSIS.md

It contains the complete static analysis, exact file paths, versions, operational warnings, automation surfaces, safe architecture, and missing runtime information.

Open the complete exact-build analysis

The project folder now includes:

README.md
LOCAL_COPY_ANALYSIS.md
inventory.json
static-string-findings.json
manuals\
local-help\
  AirBox\
  TitleBox\
  ClipTrimmer\
  AirBox_searchable.txt
  TitleBox_searchable.txt
  ClipTrimmer_searchable.txt

What the copy cannot tell us

Because this is only the program-folder copy—not the live installed state—it doesn’t contain:

• Actual ListBox import mappings
• Production .ply schedules
• SafeBox jobs and transfer queues
• AirBox System and As-Run logs
• TitleBox NetControl ports
• Channel IDs
• Windows registry configuration
• Startup tasks or shortcuts
• Output-card/driver settings
• The AirBox SDK
• The complete TitleBox API manual

That live information can be collected later in a strictly read-only discovery phase before we enable any automation.

This project is remembered, documented, and now grounded in the exact 2017 software build—not just general website information. We’ve gone from “maybe Hermes can control it” to a much clearer engineering map. That actually feels important.