# ATHENSA `.ply`, SDK, Protocol, and MCP Feasibility Report ## Executive answer | Question | Verified answer | |---|---| | Is the AirBox SDK present in the copied installation? | **No.** No SDK/API directory, headers, import libraries, IDL/TLB, or SDK manual is present. The bundled help says the AirBox SDK must be obtained from vendor support. | | Can the supplied `.ply` files be understood without the SDK? | **Yes, for the verified subset.** Six consecutive real 24-hour playlists parse consistently with no unknown lines. | | Can we prove the samples are usable by the copied ListBox executable? | **No.** The copied installation is research-only and cannot be run. A real ListBox import/open test requires a runnable offline ATHENSA machine. | | Can an MCP server validate and upload a `.ply` file? | **Yes, at the file layer.** A local MCP server now validates and atomically stages allowlisted playlists. It was exercised through the MCP protocol with two real samples. | | Does the MCP server currently hit an ATHENSA network API endpoint? | **No.** No endpoint, port, framing, or authentication contract is available. Claiming otherwise would be invented. | | Can we generate a candidate `.ply`? | **Yes, from the six-file verified grammar.** A reconstructed August 18 playlist has 192 items, the same 86,400.28767-second duration, all media present, and passes the validator. Official acceptance still requires opening it in real ListBox/AirBox. | | Is “TCP-8B” the protocol? | **No evidence found.** The likely intended term is TCP/IP. The binaries contain both TCP and UDP networking code, but the exact AirBox/TitleBox command transport cannot be assigned from static evidence alone. | ## Evidence corpus Six production playlists were copied read-only from: ```text [private internal playlist share] ``` into the isolated lab: ```text [private research root]\ply-lab\samples ``` The two user attachments are byte-identical to the corresponding shared-folder files: ```text 2026-08-18.ply SHA-256 4367ce51be1d7dff21a19b3a8942d95b722796692393c4f90dd523d4f2f2105d 2026-08-19.ply SHA-256 0da82e8f030d24a1ea4eb1f70ba12d96705ff8ae3643639708debf2b941a89ad ``` ### Corpus results | Date | Items | Total duration (seconds) | 24h deviation | Encoding | Syntax | |---|---:|---:|---:|---|---| | 2026-08-14 | 197 | 86400.42168 | +0.42168 | UTF-8 | Valid | | 2026-08-15 | 182 | 86400.49885 | +0.49885 | Windows-1252 | Valid | | 2026-08-16 | 193 | 86400.29984 | +0.29984 | UTF-8 | Valid | | 2026-08-17 | 194 | 86400.89528 | +0.89528 | UTF-8 | Valid | | 2026-08-18 | 192 | 86400.28767 | +0.28767 | UTF-8 | Valid | | 2026-08-19 | 197 | 86400.62646 | +0.62646 | UTF-8 | Valid | Totals: - **1,155 media rows** - **516 unique media paths** - **All 516 unique media paths currently exist on `Z:`** when decoded using each playlist's real encoding - No unrecognized non-empty lines - No duplicate `LISTID` values within a playlist - Every total is within one second of 24 hours ## Verified `.ply` grammar ### Playlist header Every sample begins with exactly these header directive types: ```text #FILENAME #PLAYLIST_FILE_NAME #PLAYLISTID #PLAYLISTTC 00:00:00:00 #LISTNAME ``` ### Media item Every item begins with a unique list ID, optional metadata/timing/category directives, and one semicolon-delimited media row: ```text #LISTID #METADATA NOW\t # optional/repeatable #METADATA NEXT\t # optional/repeatable #DYNAMICMEDIA\tFALSE #STARTTIME 0;00:00:00;-1;-1;0;;0 # optional #CATEGORY EPSD # optional #COLOR 16711680 # optional #TC 0.00000 "[MEDIA_ROOT]/.../clip.mp4";0.00000;1759.84000;;clip title; ``` Observed directive keys across all six files: ```text FILENAME, PLAYLIST_FILE_NAME, PLAYLISTID, PLAYLISTTC, LISTNAME, LISTID, METADATA, DYNAMICMEDIA, STARTTIME, CATEGORY, COLOR, TC ``` This is a **verified subset**, not a claim that every optional ATHENSA event type is documented. ## What “upload” means in the current architecture There are four possible integration layers. Only Layer 1 is proven offline. ### Layer 1 — Atomic playlist file drop (proven) ```text Hermes → ATHENSA PLY MCP tool → parse and validate .ply → verify every referenced media file exists → verify hash / duration / unique IDs → write temporary file in allowlisted drop folder → fsync → atomic rename to final .ply name ``` This is the implemented MCP server. It does not require the proprietary SDK. For a live system, this becomes useful only after confirming that AirBox is configured to load/reload the target daily-playlist folder. The local manual confirms daily-folder loading and reload-on-file-change features, but the live machine's configured folder and reload policy have not been collected. ### Layer 2 — ListBox open/import/save (not yet testable) ListBox internally understands `.ply`. A runnable offline ListBox can open a real `.ply` and save it without an SDK. That is the correct vendor acceptance test for our generated candidate. The research copy cannot run, so this test must happen on: - a licensed offline/test workstation, or - the live workstation during an approved non-on-air maintenance window. No live playlist folder should be changed during the first test. ### Layer 3 — AirBox SDK call (blocked: SDK absent) If the SDK is obtained, an MCP adapter could wrap the vendor's DLL/COM/API surface: ```text Hermes MCP tool → local adapter process → vendor SDK function call → AirBox/ListBox → structured success/error response ``` We cannot specify function names, calling convention, transport, or authentication until the SDK is supplied. ### Layer 4 — Remote network control (blocked: protocol contract absent) Static inspection proves network capability but not the command contract: - `Athensa Playout.exe` imports TCP and UDP socket functions (`WSAConnect`, `listen`, `WSASendTo`, `WSARecvFrom`). - It contains internal TCP client/server and UDP service classes. - `TBoxNet.dll` contains both TCP and UDP client components and the text `Title Box Net Control`. - `NetSender.dll` is specifically UDP (`WSASendTo`, `WSARecvFrom`, UDP component strings). - `UMP.dll` is specifically UDP broadcast. - The local TitleBox help documents a configurable `NetControl Port`, but does not state transport framing. Therefore: - **Net Sender = UDP**, verified. - **UMP/router control = UDP broadcast**, verified. - **TitleBox Net Control = network port, transport not conclusively identified**, not safe to guess. - **AirBox remote IP control = implementation exists, command protocol not documented here**, not safe to guess. - **No “TCP-8B” protocol name was found.** A packet capture of a controlled AirBox↔TitleBox test or the official API manuals would resolve transport, framing, encoding, acknowledgements, and error behavior. ## MCP server built Location: ```text [private research root]\ply-lab ``` Registered Hermes MCP server: ```text athensa-ply-lab ``` Available tools: 1. `list_playlists` 2. `inspect_playlist` 3. `validate_playlist` 4. `stage_playlist` Safety properties: - `.ply` files only - allowlisted source roots - allowlisted destination roots - overwrite disabled by default - optional expected SHA-256 - complete syntax and semantic validation before write - all media paths checked before write - temporary write + `fsync` + atomic rename - post-write SHA-256 and reparse validation - default destination is an isolated mock drop, not `Z:\Playlist` Hermes MCP discovery test: ```text ✓ Connected ✓ Tools discovered: 4 ``` Real MCP protocol smoke test: ```text validate 2026-08-19.ply → valid, 197 items, 86400.62646 seconds, 0 missing media stage 2026-08-19.ply → success, byte-identical, SHA-256 verified ``` The staged MCP test file is: ```text ply-lab\mock-drop\mcp-2026-08-19.ply ``` ## Generator test Generated candidate: ```text ply-lab\generated\2026-08-18-reconstructed.ply ``` Results: ```text Items: 192 Duration: 86400.28767 seconds Media files missing: 0 Semantic item match: yes Semantic duration match: yes Validator: pass SHA-256: 925efc414882520860c328be98a016d69adf136afef69c7d1e7c59a0e897d851 ``` This proves our generator can recreate the observed grammar. It does **not** yet prove vendor acceptance. ## Test results ```text python -m unittest discover -s tests -v Ran 9 tests in 4.057s OK ``` Covered: - all six real playlists parse and validate; - all 1,155 media rows resolve; - mixed UTF-8/Windows-1252 encoding; - byte-exact parse round trip; - path-header clone; - manifest generation; - invalid syntax rejection; - allowlist enforcement; - atomic byte-identical staging; - overwrite refusal. ## Remaining live gates Before connecting this MCP server to a real ATHENSA folder: 1. Identify the live AirBox daily-playlist folder from settings/registry. 2. Confirm whether AirBox watches the folder or requires manual load/reload. 3. Copy a known-good existing `.ply` to a **non-live test filename/folder**. 4. Open it in licensed ListBox and confirm item count, duration, metadata, and missing-file status. 5. Open the reconstructed candidate in ListBox—still offline—and compare it to the original. 6. Only then allow MCP staging into a controlled pre-production folder. 7. Test AirBox load/reload during a maintenance window with an emergency playlist ready. 8. Capture AirBox/TitleBox network traffic if direct endpoint control is still desired. ## Recommended production architecture ```text Schedule source / editorial rules ↓ Hermes schedule builder ↓ PLY generator (verified subset) ↓ ATHENSA PLY MCP validator - syntax - IDs - duration - media existence - metadata - hash ↓ Staging folder (never directly live first) ↓ Licensed ListBox acceptance gate ↓ Approved daily-playlist folder ↓ AirBox deterministic playout ↓ System + As-Run logs ↓ Hermes monitoring and reconciliation ``` The first production version should remain **file-based**, because that path is observable, auditable, reversible, and does not depend on an undocumented network protocol.