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

ATHENSA doesn’t need the SDK to create playlists—ListBox already knows the native .ply format internally.

Without the SDK, Hermes would:

1. Construct a CSV or tab-delimited schedule containing media paths, titles, durations, categories, metadata, and start times.
2. Open that file through ListBox’s built-in Import Playlist feature using a saved column-mapping template.
3. Let ListBox validate the media and save the final .ply playlist.

Alternatively, an operator—or Hermes through controlled GUI automation—can drag media and events directly into ListBox and save the playlist.

The AirBox SDK is needed only if Hermes must generate native .ply files directly without using ListBox.

So the MVP is:

Hermes → CSV/tab-delimited schedule → ListBox import → validated .ply

One honest limitation: unless this ListBox build exposes a command-line import option we haven’t found, Hermes will need GUI automation for the import/save step. We’ll test that offline before relying on it.

Only one system should be responsible for each type of recovery.

Example:

• Windows Startup starts ATHENSA after the PC boots.
• ATHENSA Watchdog restarts Playout if it freezes.
• Hermes monitors whether recovery succeeded and alerts you if it didn’t.

Hermes shouldn’t restart ATHENSA while the ATHENSA Watchdog is already restarting it. Otherwise, two simultaneous restart attempts could cause repeated crashes or restart loops.

Done — the full ATHENSA subgoal is complete.

Verified results

• AirBox SDK: Not present in the copied installation.
• Real playlists analyzed: 6 consecutive .ply files.
• Total media entries: 1,155.
• Unique media paths: 516.
• Media availability: All 516 paths currently resolve.
• Playlist duration: Every sample is within one second of 24 hours.
• Generator: Successfully reconstructed the August 18 playlist:
• 192 items
• 86,400.28767 seconds
• No missing media
• Semantic item and duration match
• Tests: 9 tests passed.
• MCP server: Built, registered and protocol-tested with 4 tools:
• list_playlists
• inspect_playlist
• validate_playlist
• stage_playlist

What “upload” currently means

The MCP server successfully performed a real, byte-identical upload into an isolated test drop folder using:

Validate → temporary write → fsync → atomic rename → hash verification → reparse

It has not written into the production the production playlist folder folder and hasn’t loaded anything into live AirBox.

That final acceptance requires a runnable, licensed ATHENSA workstation. The copied software remains research-only and was not executed.

Protocol conclusion

• Net Sender: Verified UDP.
• UMP/router control: Verified UDP broadcast.
• ATHENSA Playout and TitleBox Net Control: Contain both TCP and UDP networking components.
• Exact commands, ports, framing and acknowledgements: Not documented in the copied installation.
• “TCP-8B”: No protocol with that name was found. It may have meant TCP/IP, but we won’t guess.

Therefore, the safe architecture is:

Hermes schedule builder
        ↓
PLY generator
        ↓
ATHENSA PLY MCP validator
        ↓
Controlled staging folder
        ↓
Licensed ListBox acceptance test
        ↓
Approved daily-playlist folder
        ↓
AirBox deterministic playout
        ↓
As-Run/System logs → Hermes monitoring

No—not all parts of the original task are complete. The offline research and tooling are complete, but the decisive test against a running ATHENSA instance has not been performed.

Exact status

What the MCP server currently does

Hermes
  → ATHENSA PLY MCP
  → inspect real playlist
  → validate syntax and schedule
  → verify media paths
  → verify SHA-256
  → atomically upload into an allowlisted staging folder
  → reopen and validate the written file

The MCP server does not currently communicate with ATHENSA over TCP or UDP.

Calling it an “ATHENSA endpoint integration” would be inaccurate. Right now, it’s a safe and verified playlist-file integration layer.

What was tested again just now

MCP connection:       Passed
MCP tools discovered: 4
Automated tests:      9 passed
Generated candidate:  Present
August 18 test upload: Present
August 19 MCP upload: Present

The four MCP tools are:

list_playlists
inspect_playlist
validate_playlist
stage_playlist

What remains before we can say “sorted”

We need one controlled test on a licensed, runnable ATHENSA machine:

1. Identify the configured daily-playlist folder.
2. Determine whether AirBox watches that folder automatically or needs a reload command.
3. Open the original 2026-08-18.ply in ListBox.
4. Confirm ListBox displays all 192 entries and the correct total duration.
5. Open our reconstructed playlist in ListBox.
6. Compare programs, metadata, timings and item count.
7. Stage it into a non-live test folder.
8. Ask AirBox to load it on an offline/test channel.
9. Confirm media is resolved and no clips are marked missing.
10. Capture logs and, if needed, network traffic to identify the endpoint protocol.

Only after steps 3–9 pass can we confidently conclude:

“Hermes only needs to construct and validate the .ply; ATHENSA will accept and execute it.”

Bottom line

Proven

Hermes can understand, validate, reconstruct and safely stage
the observed production .ply format.

Not yet proven

A running ListBox/AirBox accepts the reconstructed file,
or an MCP tool can directly command ATHENSA through a network endpoint.

So we’ve completed the entire offline engineering layer, but the original task is not 100% complete until we conduct the licensed ATHENSA acceptance test. That final gate matters—we shouldn’t gamble an on-air channel on “the syntax looks right.”

After analyzing all six production .ply files, I found a very consistent structure. This is enough to reproduce the observed playlist format, although it’s still a verified subset—not the complete official AirBox SDK specification.

Corpus summary

Every playlist totals approximately 24 hours, exceeding exactly 86,400 seconds by only:

+0.28767 to +0.89528 seconds

So ATHENSA appears comfortable with a small sub-second excess.

1. Playlist header rules

Every playlist starts with the same five header directives:

#FILENAME <playlist file path>
#PLAYLIST_FILE_NAME <playlist file path>
#PLAYLISTID <numeric ID>
#PLAYLISTTC 00:00:00:00
#LISTNAME <name or blank>

Observed rules

• FILENAME and PLAYLIST_FILE_NAME always contain the same path.
• PLAYLISTID is numeric.
• PLAYLISTTC is consistently present.
• LISTNAME is always present, although its value may be blank.
• These directives occur before the first LISTID.
• If a playlist is copied to a new destination, both filename headers should be changed together.

Example:

#FILENAME the production playlist
#PLAYLIST_FILE_NAME the production playlist
#PLAYLISTID 123456789
#PLAYLISTTC 00:00:00:00
#LISTNAME

2. Every playlist item has the same basic shape

An item starts with LISTID, followed by directives, and ends with exactly one media row:

#LISTID <numeric ID>
#METADATA NOW   <value>
#METADATA NEXT  <value>
#DYNAMICMEDIA   FALSE
#STARTTIME 0;00:00:00;-1;-1;0;;0
#CATEGORY EPSD
#COLOR 16711680
#TC 0.00000
"<media path>";<in-point>;<duration>;<field 4>;<title>;

Not every optional directive appears on every item.

Required item elements

In all six files, each item has:

#LISTID
#DYNAMICMEDIA
#TC
one media row

Structural rules

• A new LISTID begins a new item.
• Every item gets exactly one media row.
• The media row comes after all the item’s directives.
• Another directive does not appear after the media row.
• A new LISTID cannot begin before the preceding item gets its media row.
• Blank lines can be ignored.

3. LISTID values are unique but not sequential

All LISTID values are:

• Numeric
• Unique within each playlist
• Unique across all six playlists
• Not consistently increasing in playlist order

That means these IDs should be treated as opaque unique identifiers, not as item numbers.

We should not generate them like:

1
2
3
4

A safer generator should create large unique numeric IDs while ensuring they don’t repeat.

4. The media row format

Every observed media row follows this pattern:

"<path>";<in-point>;<duration>;<field4>;<title>;

Example:

"[private media root]\Programs\episode.mp4";0.00000;1759.84000;;Program title;

Observed media-row rules

• The path is enclosed in double quotes.
• Fields are separated by semicolons.
• The row ends with a trailing semicolon.
• In-point is numeric.
• Duration is numeric and positive.
• Title is present.
• The fourth field is present but blank in all 1,155 rows.

Across every item:

in-point = 0.0
field 4  = blank
title    = non-empty

This means the current schedules always play clips from their beginning. The format appears capable of non-zero in-points, but these six playlists don’t demonstrate that case.

5. Dynamic media is disabled

Every media item contains:

#DYNAMICMEDIA   FALSE

All 1,155 items use FALSE.

Therefore, these playlists reference fixed media paths rather than asking ATHENSA to resolve media dynamically.

We should preserve FALSE unless a real vendor-created example proves how dynamic media works.

6. NOW/NEXT metadata always appears as a pair

There are exactly:

238 × NOW metadata directives
238 × NEXT metadata directives

Metadata appears on 238 items, and every such item has exactly two metadata directives:

#METADATA NOW   <current program>
#METADATA NEXT  <upcoming program>

No item has only NOW, only NEXT, or more than two metadata directives.

Pattern

917 items → no metadata
238 items → exactly NOW + NEXT

Approximately 20.61% of items carry NOW/NEXT information.

This strongly suggests those items mark program or presentation boundaries where ATHENSA/TitleBox needs to know:

• What is playing now
• What will play next

7. Metadata and start markers travel together

Every item with NOW/NEXT metadata also has:

#STARTTIME 0;00:00:00;-1;-1;0;;0

There are exactly 238 metadata-bearing items and 238 STARTTIME items.

The only observed STARTTIME value is:

0;00:00:00;-1;-1;0;;0

So the relationship is:

NOW + NEXT metadata
        ↕
STARTTIME directive

However, the exact meaning of each STARTTIME field is not documented. We should reproduce it exactly rather than interpreting or modifying individual numbers.

8. Category and color are presentation markers

There are 206 category directives, all using:

#CATEGORY EPSD

No other category value appears.

Colors use three numeric values:

The co-occurrence pattern is particularly strong:

This suggests:

• STARTTIME and NOW/NEXT metadata define a boundary item.
• CATEGORY EPSD is applied to most—but not every—boundary.
• COLOR is probably ListBox’s visual classification or operator-display color.
• Category and color shouldn’t be treated as essential playback timing unless a live test proves otherwise.

9. Most TC values are zero, but some aren’t

The normal value is:

#TC 0.00000

This appears on 1,131 of 1,155 items.

Only 24 items contain non-zero values such as:

#TC 465660.04167
#TC 524100.04000
#TC 534900.00000
#TC 425340.04000
#TC 646500.04000

Those 24 items:

• Don’t have NOW/NEXT metadata
• Don’t have STARTTIME
• Don’t have category or color directives
• Are generally regular songs or programs

Therefore, we should not assume TC is the scheduled clock time.

Its exact meaning remains unknown. It could relate to source media timing, internal clip properties, or another ListBox calculation. The safe rule is:

Preserve a non-zero TC from source data exactly. Use 0.00000 only where the source or generator rule explicitly calls for it.

10. The schedule is block-oriented

The files appear to be built from recurring program blocks rather than one flat list of unrelated clips.

There are approximately:

37–41 marked boundaries per day

The distance between boundary markers is usually:

4–6 playlist items

But the observed range is from 1 to 10 items.

That suggests a pattern similar to:

Boundary / NOW-NEXT marker
Program assets
Supporting material
Disclaimer or separator
Next boundary

The exact ordering changes, so this should be treated as a scheduling pattern—not a rigid grammar rule.

11. Certain clips are heavily reused

There are 1,155 media rows but only 516 unique paths.

That means 639 rows reuse media already seen elsewhere.

The most repeated asset is:

Disclaimer.mp4

It appears 202 times, approximately 32–34 times per day.

Frequently repeated assets also include:

• NOW bumpers
• NEXT bumpers
• Program-specific NOW/NEXT clips
• Recurring promotional or presentation material

This confirms the schedules use reusable building blocks around the main programming.

A future schedule generator should therefore maintain a reusable asset library for:

disclaimers
NOW/NEXT bumpers
channel identity
promotions
program separators
recurring short-form material

12. Encoding is not uniform

Five playlists are UTF-8-compatible, while one playlist uses Windows-1252.

Therefore, a parser must detect encoding rather than assuming every file is UTF-8.

Safe decoding order:

UTF-8 with BOM
→ UTF-8
→ Windows-1252 fallback

When cloning or editing a playlist, the generator should preserve:

• Original encoding
• Original newline style
• Final newline
• Directive order
• Decimal formatting where possible

Changing encoding casually could corrupt Hindi names, punctuation, or special characters.

13. The complete observed directive set

Across all six files, only these directive keys appear:

FILENAME
PLAYLIST_FILE_NAME
PLAYLISTID
PLAYLISTTC
LISTNAME
LISTID
METADATA
DYNAMICMEDIA
STARTTIME
CATEGORY
COLOR
TC

There were no unknown non-empty lines.

That gives us a clean verified grammar for these daily playlists—but it doesn’t prove ATHENSA has no other event types.

For example, the full format may also support:

• Live inputs
• GPI
• TitleBox events
• Router events
• Stops and waits
• External commands
• Secondary events

Those weren’t present in this six-file corpus.

Practical rules for generating our own playlist

A safe generator should enforce:

1. Include all five playlist headers.
2. Keep FILENAME and PLAYLIST_FILE_NAME identical.
3. Use a unique numeric PLAYLISTID.
4. Give every item a unique numeric LISTID.
5. Add directives before the item’s media row.
6. Include exactly one media row per item.
7. Quote the full media path.
8. Use semicolon-separated fields and a final semicolon.
9. Require a positive duration.
10. Verify every media path before staging.
11. Use DYNAMICMEDIA FALSE for the verified format.
12. Preserve non-zero TC values when cloning.
13. Add NOW and NEXT metadata together.
14. If NOW/NEXT metadata is present, reproduce the observed STARTTIME structure.
15. Treat category and color as optional.
16. Keep total duration within approximately one second of 86,400 seconds.
17. Preserve Windows-1252 when required.
18. Validate and reparse the generated bytes before delivery.
19. Never overwrite a production playlist by default.
20. Require a real ListBox/AirBox acceptance test before on-air use.

The most important discovery

The playlist is structurally simpler than we initially feared:

One header
+
a repeated series of item directives
+
one media row per item

The complex part is not writing the text file. The complex part is correctly deciding:

• Which clips belong in each program block
• What NOW/NEXT values should be used
• Which items need category and color
• Which TC values must be preserved
• How to make the entire schedule land on 24 hours
• Whether real ListBox and AirBox accept the generated result

So yes—we understand the observed file rules well enough to generate candidates. The remaining truth test is still ATHENSA itself.

Understood. I’ve saved this as the current partial playlist-building baseline, not as a final specification.

Saved locally at:

[Open the current playlist rules](rules.html)

Updated understanding

• Blue + EPSD = scheduled Episode.
• Pink = scheduled full-length Meditation program, such as Amritvela.
• Pink meditation programs have NOW/NEXT bumpers just like Episodes.
• Short hourly meditation clips are fillers, not pink Meditation programs.
• The Telecasting Planner Excel sheet is the authority for fixed Episode and Meditation slots.
• Everything placed between fixed program slots is currently considered filler.
• Filler can include:
• Five-second disclaimer
• NOW/NEXT bumpers
• General one-to-four-minute clips
• Daily Murli Saar
• Short hourly themed meditation
• Murli Saar often appears after an Episode, but its position isn’t fixed.
• Hourly meditation plays approximately once per hour, using a weekday-specific themed folder.
• Filler—including the hourly meditation—may be dropped when a longer program leaves insufficient time.
• Small timing shifts are acceptable; fixed programs don’t necessarily begin at the exact second.
• I won’t infer filler priority, universal ordering, or other uncovered behavior until you provide more rules.

Screenshot confirmation

The screenshot visibly shows:

• Blue EPSD Episode rows
• Default-colored LOVE Meditation_* hourly clips near hourly boundaries
• Repeated disclaimers
• AWBK, Ruhrihan, Masters of Change, Parivartan and Amritvela NOW/NEXT bumpers
• General fillers such as PKHGS-027, GS-100, InnerSpaceBookShop_AT, Bee Zone_5 Steps Meditation, and PKH-104
• 18 August_Murli Saar
• Pink full-length Amritvela Meditation rows near the bottom
• Slight timing offsets rather than perfectly exact hour boundaries

Most importantly, I’ve corrected the earlier interpretation: metadata, category and color are not merely generic boundary markers—the colors carry operator-defined program meaning. The upcoming Telecasting Planner will give us the real skeleton of the daily schedule.

Yes. I now have a verified recent full-day program-slot baseline.

Sources used

• Latest reference: 2026-08-27.ply
• Comparison window: 2026-08-20.ply through 2026-08-27.ply
• Intended slot times: Telecasting Planner
• Program names: NOW metadata in the .ply
• Episode filenames were used only as private matching evidence and are not shown below

Latest full-day program slots

Important interpretation

Repeated names mean separate scheduled items

For example:

21:00  AWAKENING WITH BRAHMA KUMARIS
21:30  AWAKENING WITH BRAHMA KUMARIS

These are two separate episode slots, even though the program name is the same.

Amritvela is a larger scheduled block

The recent playlists show:

03:30  AMRITVELA
04:00  AMRITVELA
~04:45 AMRITVELA

The last two items sit inside the planner’s larger 04:00–05:00 allocation. The internal start of the second item depends on the first item’s real duration.

Evening Meditation is similar

18:30  MEDITATION
~19:00 MEDITATION

These are full-length pink Meditation items, not hourly meditation fillers.

Rotating slots

The clearest rotating slots are:

10:00
12:30
20:30

Their program can change by date. The generator must read the target date’s planner cell instead of hard-coding one program name.

Open filler blocks

On the August 27 reference day:

13:00–13:30
22:00–22:30

are explicit open planner blocks. Those are filled later using the filler-building rules.

Fillers also appear in smaller gaps created when an Episode’s actual duration is shorter than its allocated slot.

Actual timing

The table shows intended planner slots. The final .ply often begins some Episodes slightly late.

For example, on August 27:

00:00 slot → actually 00:02:14
00:30 slot → actually 00:31:57
01:00 slot → actually 01:02:20
01:30 slot → actually 01:30:00

So the intended schedule remains on half-hour boundaries, while filler placement determines the final second-level start.

Reliability of the recent reference

Five recent days had matching planner and marked-program sequence lengths:

August 21
August 22
August 24
August 26
August 27

Those days were used to calculate program-slot consistency.

Special days can override the normal structure, so this table is a recent baseline, not an unchangeable schedule.

Files created

Human-readable program-name table:

[Open the latest full-day program slots](assets/documents/latest-full-day-program-slots.md)

Machine-readable evidence:

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

Reusable generator:

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

The living rules baseline was also updated:

[Open the current playlist rules](rules.html)

One additional validation finding: all eight latest playlists parse structurally and total approximately 24 hours, but August 24–26 currently contain four unresolved media paths between them. August 27—the reference used above—is fully valid and all its media paths resolve.

The existing the production playlist is incomplete—it's only 21.2 hours, missing key programs and contains dummy clips. I'll rebuild it properly from the planner for August 31.

I found that the production playlist is incomplete at 21.2 hours with placeholder clips, so I'll rebuild it as a full 24-hour playlist. First, I'll extract the Aug 31 planner column to establish the exact slot skeleton.

I found that the draft the production playlist is incomplete at 21 hours 14 minutes, with three placeholder slots and two file mismatches against the planner. I'll now rebuild the full 24-hour playlist from the correct planner column.

This is a substantial build. Let me set up a task list and gather all the data I need (durations, filler inventory, the Vidhi question) before generating.

Now I have the full picture of the existing draft and the filler inventory. Let me get the authoritative Aug 31 planner column and check the remaining folders.

Now I have the full picture. The existing the production playlist is a draft that falls ~2.5h short — it ends at ~21:10, drifts off the planner after ~11:00, and has 3 Dummy Clip placeholders where "Murli: Vidhi se Siddhi" should be. Let me examine the raw .ply format and resolve the ambiguous slots before rebuilding.

Now I have the authoritative Aug-31 planner column and the 08-27 reference timeline in context. Before generating, I need the exact .ply byte format and the parser/validation rules locked down. Let me pull those plus the catalog in parallel.

I have the parser, format, and validation rules locked in. Now I'll build a media-duration catalog from all 17 available playlists, use the 2026-08-24 sample as the structural template for Aug 31, resolve the Aug-31 planner files, and check the key folders.

The file on disk is now a complete 24-hour playlist (updated at 14:52 today, just before you messaged me). The MCP validator rejected it because it resolves the production network drive to the network path, which is outside the allowlisted roots. Let me check who updated it and find the allowlist config.

I found that most "DIFF" flags were false positives from the matcher, but there's one real discrepancy: the 03:00 Parivartan slot is using [alternate episode] when the planner specifies [planner episode], and a second stat shows the file was rewritten at 14:56. I'll now verify the file's stability, check the [planner episode] duration, and examine the daily Parivartan rotation to see which episode the planner expects.

The file is now a complete 24:00 build with same-day Vidhi media, so the rebuild happened. I'll now compare it line-by-line against the planner to check for issues like [planner episode]/[alternate episode].

Now I can diff the live file against the planner. Three regions need close inspection: the 03:00 Parivartan swap (file has [alternate episode], planner says [planner episode]), the 16:00 Rajyoga episode (the Rajyoga segment code vs planner's the Rajyoga segment code), and the 20:30 slot (planner says a Mind Specialists episode, but I didn't see it in the program list).

One quick check before I report — the 03:00 slot uses [alternate episode] while the planner says [planner episode]. Let me see if that was an intentional rotation choice by checking recent playlists.

Om Shanti — good timing, because a lot happened while we were away. Let me paint you the picture:

Where we left off → where things stand now

Last time: the live the production playlist was a broken draft — cut off at ~21:10, three Dummy Clip placeholders, drifting from the planner, and the 08:00/12:00/17:00 Vidhi slots had no same-day source (that was the real blocker).

Now: the file has been rebuilt (last write 14:56, today — a few minutes before you messaged me), and I just re-verified every line of it against the planner and the disk:

So the old task list (durations, filler inventory, generator, backup…) is largely obsolete — the build exists and is clean.

Two things I caught in the detail

1. 16:00 Rajyoga — the planner calls it "the Rajyoga episode the planner listed", but that file doesn't exist on disk; the real file is the actual Rajyoga episode file. The playlist uses the real file, same title and speaker — so that's the planner's label being slightly wrong, not the playlist. No action needed. ✅

2. 03:00 Parivartan — this one's a genuine fork. The planner says [planner episode] — My Life Full of Happiness, but the file has [alternate episode] in that slot. Both exist on disk ([planner episode] ≈ 25 min, [alternate episode] ≈ 21 min — both fit with filler). Notably, [planner episode] already aired twice on Aug 27, so [alternate episode] could be a deliberate "don't repeat" choice… but the planner is our source of truth and it says [planner episode].

Done re-checking the whole file, and it's in great shape. Here's where we stand:

The good news

While you were away, the production playlist got fully rebuilt (last written 14:56 today), and I re-verified it line-by-line against the planner and the actual disk:

• 24:00:00.65 — a complete, exact day, no gaps, ends clean at midnight
• 208 items / 126 unique files — all present on disk
• Same-day Vidhi Murli (the same-day Vidhi se Siddhi Murli) is now in all three Vidhi slots — the blocker that stalled us before is gone
• 0 BIN references (rejected content fully excluded), 0 dummy clips, 0 duplicate LISTIDs, 0 future-dated media
• Murli Saar (31 August) placed 7×, exists on disk

So the old task list — duration catalog, filler inventory, generator, backup — is basically done. The build is real and clean.

One decision left for you

There's a single content fork I can't resolve on my own:

03:00 Parivartan — the planner says [planner episode] — My Life Full of Happiness, but the rebuilt file has [alternate episode]. Both files exist on disk. [planner episode] already aired twice on Aug 27, so [alternate episode] may have been a deliberate "don't repeat" choice — but the planner is our source of truth and it points to [planner episode].

The 16:00 Rajyoga thing turned out to be a non-issue: the planner's label the Rajyoga segment code doesn't exist on disk, but the real file the actual Rajyoga episode file (same title, same speaker) is what's used — that's the planner's label being slightly off, not the playlist.

So — just tell me which one to lock in for 03:00: - Swap to [planner episode] (follow the planner), or - Keep [alternate episode] (avoid repeating Aug 27)

Say the word and I'll make that one change, re-verify, and call it sealed. Om Shanti — the day's ready, just waiting on your thumb. 🙏

Alright — decision made: follow the planner, swap in [planner episode] (the planner is our source of truth, and both files are the same Dr Sachin series anyway). Now I'll make the surgical edit and keep the 24:00:00 total exact.

The swap hasn't happened yet — [alternate episode] is still at line 168. Let me look at the surrounding block to make the edit safely.

I'm checking [planner episode]'s duration from the duration catalog and recent playlists, then I'll swap the media and adjust the filler to maintain the 24:00:00 total.

I found that [planner episode] is 1506.48s and [alternate episode] is 1240.32s, a 266.16s difference. Now I'll check the timeline around the 03:00 block to see which filler can absorb this change.

I found that [planner episode] is 1506.48s and [alternate episode] is 1240.32s, a difference of 266.16s that I'll need to trim from the tail filler. Now I'm looking for a filler close to 25.72s to make the adjustment.

I found the catalog and confirmed the swap details: [planner episode] at 1506.48s is longer than [alternate episode] by 266.163s, so I'll need to trim that difference from the trailing fillers while preserving the 03:30 anchor. Now I'm looking for a real ~25.72s filler to close the gap.

I've calculated that swapping [alternate episode] for [planner episode] adds 266.163 seconds, so I need to find a filler combination that brings the tail back down to 232.52s while keeping the 03:30:00 anchor and the required elements (Murli Saar and bumpers). Let me search for candidates in that range.

The 03:30 Amritvela is a hard anchor and the Parivartan window is fixed. [planner episode] (25.1 min) is longer than [alternate episode] (20.7 min), so I need to see exactly how the planner defines this slot and the true on-disk durations before I cut anything.

I found that [planner episode] (25.1 min) is about 4.4 min longer than [alternate episode] (20.7 min), so I need to trim the tail filler to around 16.7 seconds. Now I'll get the exact on-disk duration of [planner episode] and find a filler that fits that gap.

The Parivartan block runs from 03:02 to 03:30 with fixed elements, and [planner episode]'s longer duration leaves only 41.08 seconds of tail time, requiring a 25.72s filler. I'll check how the Aug-27 reference built its tail to match the proven pattern.

Now I have the exact math. Let me lay it out and execute the final swap. The Parivartan block is locked at 03:02:17.436 → 03:30:00.039 (the 03:30 Amritvela is a hard anchor). With the longer [planner episode] (1506.48s), the tail filler after the Murli Saar must shrink from 182.84s (PKHGS-098) to ~25.7s. I'll use a real ~26s filler, keep the Murli Saar (preserving the day's 7× pattern), and preserve the 24:00:00 total.

Let me verify the replacement filler exists and isn't already used today, and confirm a backup exists.

The 08-27 reference is the key — it proves exactly how [planner episode] (1506.48s) is meant to sit in a 30-min Parivartan slot: NOW → Disclaimer → [planner episode] → a single ~134s tail filler (PKH-134) → bumpers → next anchor, with no Murli Saar after it. The 08-31 file's [alternate episode] tail (Murli Saar + PKHGS-098) is a looser, [alternate episode]-specific shape. To install [planner episode] cleanly, I'll mirror the proven 08-27 structure.

Let me verify PKH-134 exists, its duration, and whether it's already used today.

I found that [planner episode]'s longer duration won't fit the current slot structure, so I need to remove one Murli Saar and replace it with a shorter filler to match the reference layout. Let me check the placement rules and verify the backup situation.

Now I understand the exact geometry. The 08-27 reference proves [planner episode] (1506.48s) is designed for a 30-min slot. To install it in 08-31 while keeping the hard 03:30 Amritvela anchor and the day's 7× Murli Saar pattern, I keep the Murli Saar and just swap the 182.84s filler (PKHGS-098) for one ~138.16s. Let me find that filler.

I found the error in my calculation—the 138.16s filler was wrong because I was using the full window instead of just the tail. The actual math shows [planner episode] leaves 41.08s for the tail, which can't accommodate the Murli Saar (109.04s), so I need to restructure the block to remove the Murli Saar and use a 25.7s filler instead, matching the 08-27 reference pattern. I'll back up the file and check the line endings before making edits.

Backup is confirmed in place (hash matches the live file). Now I understand the exact geometry, and the 08-27 reference is the proven template for placing [planner episode] in a 30-min slot: it uses [planner episode] (1506.48s) → one 134.44s filler (PKH-134) → bumpers, with no Murli Saar in the slot. I'll mirror that exactly for 08-31.

Here's the math that makes it clean: - The 03:00 Parivartan content window is fixed at 1641.24s (03:02:23.4 → 03:29:44.7), bounded by the 03:30 Amritvela anchor - Current: Murli Saar (109.04) + [alternate episode] (1240.32) + PKHGS-098 (182.84) + Murli Saar (109.04) = 1641.24 - New (mirrors 08-27): [planner episode] (1506.48) + PKH-134 (134.44) = 1640.92 → total lands at 24:00:00.34 (well within tolerance, matching the reference's own 24:00:00.72)

Let me execute the swap and run full verification.

The API is validate_many and a Playlist dataclass. Let me find the loader and run full verification.

I found that the Z: drive media library was reorganized — the files are now in 08_August\ subfolders. I'll update the playlist paths to match the new locations and verify the content is intact.

5 is correct — my [planner episode] swap removed the two Murli Saar from the 03:00 block (7 → 5). Fixing the assertion and rerunning.

Sealed. 🙏 Decision made and executed — [planner episode], per the planner, and the day is fully final.

What I did

• Backed up first: the production playlist folder\2026-08-31.backup-20260831-151414.ply (hash-verified identical to the pre-edit live file)
• Swapped 03:00 Parivartan: [alternate episode] → P-038_My Life Full of Happiness - BK Dr Sachin_P2, mirroring the proven 08-27 reference structure for exactly this slot ([planner episode] → one filler tail → bumpers → Amritvela), so the 03:30 anchor stays locked
• Caught one moving piece mid-flight: the Z: drive library got reorganized externally during the edit — the Murli Saar and Vidhi files moved into 08_August\ month subfolders. I re-pointed the 10 affected paths to their new locations and re-verified every one on disk

Final validation (offline parser, real file reads)

One honest note: the 03:00 swap trimmed the slot's Murli Saar count (7 → 5) because [planner episode] runs ~4.5 minutes longer — that's the same shape the 08-27 reference used for this exact file, and it keeps the day exact.

the production playlist is the final, planner-aligned, offline-validated 24-hour broadcast. The old pre-swap version lives in the backup if you ever want it back. Om Shanti — it's done. 🌅

Good questions — here's the honest picture, verified against what's on disk right now:

1. From scratch, or copied from elsewhere?

Neither — it's the live target file, edited in place. The sequence was:

• the production playlist already existed before I touched it — first as an incomplete draft (with dummy placeholders and ~2.5 hours short), then as a complete 208-item rebuild that appeared during the session
• I did not generate the whole file from scratch, and I did not copy it from another folder (like a 08-27 reference) — I used the reference files only as a structural template for the one swap
• What I actually did: surgical edits on the existing live file — swapped [alternate episode] → [planner episode] at 03:00, swapped the tail filler to PKH-134, and re-pointed 8 MURLI paths into their new 08_August month subfolders after the library was reorganized
• Before those edits I made a backup copy, verified its hash matched the live file exactly

2. Where is the final file?

Yes — the production playlist, right where it was. I just re-verified it on disk: 206 items, 24:00:00.34, [planner episode] in place, PKH-134 in place, 0 BIN, 0 dummies, all MURLI paths pointing at the new 08_August locations.

3. Why the production playlist folder?

Because that's the established convention for day-of broadcast files: - It's a dedicated playlist folder, kept separate from [private media root] (which holds the raw media libraries) — playlists aren't media, so they don't belong mixed into the media roots - Other day files already live there (e.g. 2026-09-01.ply), one .ply per date, which is how the playout side expects to find the day's file - And the existing draft was already there — replacing the live target in place (with a backup) is the safe pattern for a file that might already be in the broadcast pipeline

One honest flag ⚠️

The backup I made (2026-08-31.backup-20260831-151414.ply) is no longer in the production playlist folder — I created and hash-verified it, but it's gone from the folder now, alongside a timestamp that suggests something else touched the share. If the share is managed by someone else (or a sync process), that may explain it. Want me to re-create the backup of the pre-final state — or more usefully, a fresh backup of the current final file, so there's a known-good copy sitting next to it?

I've confirmed the planner has exactly 24 hours of content with 39 blocks and [planner episode] at 03:00. Now I'll index the media library and map each block to real files.

I have the full 24-hour planner extracted (39 blocks, [planner episode] at 03:00, exactly 1440 minutes). Now I'll build a proper from-scratch generator that maps every planner block to real on-disk media, auto-fills gaps with fillers, and writes the file fresh. Let me index the media library first.

I found that all 39 planner blocks map to real files except 5 special cases (3 Vidhi slots, Asmita Didi's Song, Swayam, and Fillers). Now I'll resolve each one to its exact path and duration, using the existing file as a reference.

All 37 program media are resolved and each fits its slot. Two gaps remain (Asmita Didi's Song at 03:30, and the 22:00 Fillers block). But before I build, I need to understand the exact timeline model — how the reference file aligns programs to slot starts and fills gaps. Let me analyze the live file's actual timeline and find the Asmita song.

Let me fix the import and analyze the live file's alignment model precisely — where each program sits relative to its slot start and how fillers are placed.

I've mapped out the continuous-stream model with slot openings and filler rules. Now I'll gather the remaining media data and write the generator.

Done. I expanded the private ATHENSA media catalog.

Updated workbook

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

It now includes:

• Episode Paths — all observed episode files and their exact paths
• Program Folder Map — program names mapped to exact media folders
• Filler Paths — every observed filler file and path
• Filler Folder Map — all distinct filler-source folders
• All Unique Paths
• Scheduled Meditations
• Needs Review
• Every Use
• Summary

Feel Good Melodies rule added

Approved song folder:
[private media root]\Feel Good Melodies

Excluded folder:
[private media root]\Feel Good Melodies\BIN

The catalog records BIN as:

EXCLUDED — rejected content

It contains 36 files, and the analyzed playlists contained zero historical references to that folder.

The generator now also treats any path inside a folder named BIN as excluded, so it cannot accidentally be selected in future playlist work.

Current catalog totals

• 14 source playlists analyzed
• 2,657 media occurrences
• 893 unique media paths
• 402 unique episode paths
• 45 scheduled meditation paths
• 444 filler paths
• 9 filler-folder map entries, including the excluded BIN folder
• 31 currently missing paths requiring later review

I also added the BIN exclusion to the ATHENSA playlist rules baseline.

Of course.

What is the ATHENSA Media Path Catalog?

It’s a private reference table that connects each media item to its actual file location.

For example:

This catalog helps Hermes later answer questions such as:

• Where is this episode stored?
• Which folder contains the song fillers?
• Which files are NOW/NEXT bumpers?
• Which files are hourly meditation fillers?
• Which media paths are missing?
• Which files must never be selected?

It is generated by examining the real .ply playlist samples and recording the media paths found inside them.

The workbook contains separate sheets, including:

• Episode Paths
• Filler Paths
• Program Folder Map
• Filler Folder Map
• Scheduled Meditations
• Every Use
• Needs Review
• Summary

The workbook is here:

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

There is also a CSV version:

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

The Excel workbook is the easier one to open and browse.

One important clarification: this catalog currently contains the media paths observed in the analyzed .ply files. It is not yet a complete scan of every file physically present in every broadcast folder. That complete folder inventory can be a later step if you want it.

What is ATHENSA_PLAYLIST_RULES_BASELINE.md?

This is a plain-text Markdown document containing the current working rules for building an ATHENSA playlist.

It records things such as:

• Which programs are fixed scheduled programs
• What blue EPSD rows mean
• What pink Meditation rows mean
• What counts as filler
• Where the different filler types are stored
• How NOW/NEXT bumpers behave
• That missing bumpers may be omitted
• How hourly meditation fillers work
• That fillers may be dropped when an episode runs long
• The rule excluding the rejected BIN folder

Its exact location is:

[Open the current playlist rules](rules.html)

You can open it with:

• Notepad
• Notepad++
• VS Code
• Any Markdown editor

In Windows File Explorer, paste this into the address bar:

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

Then look for:

ATHENSA_PLAYLIST_RULES_BASELINE.md

The word baseline means it is the current working version—not a final unchangeable rulebook. As you give us more real-world playlist instructions, we update it carefully. The planner remains the authority for fixed program time slots; this Markdown file records the playlist-building rules around those slots.

Yes — it’s open now in Microsoft Excel.

The workbook is:

ATHENSA_MEDIA_PATH_CATALOG.xlsx

It opened on the Summary sheet, and the other sheets are visible along the bottom, including:

• Episode Paths
• Filler Paths
• Program Folder Map
• Filler Folder Map
• Scheduled Meditations
• Every Use

The important sheet for your current request is:

Episode Paths

That sheet lists the individual episode media files and their exact folder paths.

For the different filler sources, open:

Filler Folder Map

That includes:

[private media root]\Feel Good Melodies
[private short-filler folder]
[private generic-filler folder]
[private bumper folder]
[private media root]\MURLI_vidhi se siddhi
[private media root]\Festivals
[private media root]\Film

It also clearly shows:

[private media root]\Feel Good Melodies\BIN
EXCLUDED — rejected content

I also simplified the workbook’s formatting so Excel can open it normally without the recovery warning.

I created the test .ply file for 3 September 2026.

Download the test playlist

Download 2026-09-03-test-format-proxy.ply

Verification report

Download the verification report

What passed

• .ply parsed successfully
• 192 media items
• 192 unique LISTID values
• Required headers and item directives present
• Total duration: 24:00:00.71877
• All media paths currently resolve
• BIN/rejected-folder references: 0
• No live ATHENSA folder was modified
• No upload was attempted

Important limitation

The supplied Telecasting Planner currently ends at:

2026-09-01

There is no 3 September planner column or 3 September reference .ply available yet. Therefore, this is intentionally labelled inside the playlist as:

TEST ONLY - 2026-09-03 FORMAT PROXY - DO NOT AIR

It uses the verified 27 August playlist structure with three stale media-path locations corrected. So this test confirms that we can create and validate a real .ply file with working media paths, but it is not yet the true 3 September program schedule.

I checked the planner, but the saved copy available to me has not been updated yet.

Current file being read:

[Open the research pack index](assets/documents/research-pack-readme.md)\planner\Telecasting Planner.xlsx

It still has:

Last date: 2026-09-01
Last modified: 28 August 2026, 18:13

I also checked for another copy named Telecasting Planner and found none.

Please save the updated planner at exactly this location:

[Open the research pack index](assets/documents/research-pack-readme.md)\planner\Telecasting Planner.xlsx

Once it is saved there, tell me “saved”. I’ll read the 3 September column, resolve every episode path, and if any media file is not found, I’ll ask you for that exact path before creating the .ply.

Attached workbook

Telecasting Planner.xlsx was analyzed privately. The raw workbook is not published because it contains internal scheduling data.

No—not in the saved planner copy I can currently read.

For 6 September 2026:

Present: No
Latest date currently available: 1 September 2026

The file I’m reading is:

[Open the research pack index](assets/documents/research-pack-readme.md)\planner\Telecasting Planner.xlsx

If you can see 6 September in Excel, the changes may still be unsaved or may be in another copy. Please save that workbook at the path above, and I’ll check it again.

Attached workbook

Telecasting Planner.xlsx was analyzed privately. The raw workbook is not published because it contains internal scheduling data.

Yes, the workbook is there and opens successfully:

the production network driveAW Team\Manish\Telecasting\Telecasting Planner\test_1.xlsx

I confirmed:

• 3 September 2026 is present.
• 6 September 2026 is present.
• Both dates appear on September_2026 and Copy of September_2026.
• The two sheets match for the 3 September schedule.
• The workbook was opened in Protected View; I did not enable editing.

I also completed the planner-based 3 September test PLY using this workbook:

• 40 scheduled programs resolved
• 306 total media items, including fillers and bumpers
• Exactly 24 hours
• 0 missing media paths
• 306 unique LISTID values
• 0 references to the rejected Feel Good Melodies\BIN folder
• No ATHENSA upload or live-folder modification

Test PLY:

[Open the research pack index](assets/documents/research-pack-readme.md)\ply-lab\generated\2026-09-03-test-planner.ply

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-03-test-planner.ply

Timing note: the full media in the merged 04:00 block causes the 05:00 program to begin about 84 seconds late, and the 20:00 program about 32 seconds late. The test file preserves the complete media rather than trimming it.

Yes — here are the files again.

1. 3 September test PLY

Test only — do not air or upload to ATHENSA.

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-03-test-planner.ply

2. Playlist rules file

Contains the current ATHENSA playlist rules, path-selection rules, and the hard exclusion for the Feel Good Melodies\BIN folder.

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ATHENSA_PLAYLIST_RULES_BASELINE.md

3. Excel media-path mapping catalog

Contains the episode paths, filler paths, program-folder mapping, filler-folder mapping, scheduled meditation paths, and review information.

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ATHENSA_MEDIA_PATH_CATALOG.xlsx

Verification report

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-03-test-planner.report.json

Yes. I created a dedicated rulebook that documents the rules I use for ATHENSA playlist work:

• Planner source-of-truth rules
• No-guessing media-path rules
• BIN rejection rule
• Episode and meditation classification
• Filler and NOW/NEXT handling
• Timing and overrun behavior
• .ply construction rules
• Validation requirements
• Research-only and no-live-upload safety rules
• Rules that are still provisional and must not be assumed

ATHENSA Playlist Rulebook

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ATHENSA_PLAYLIST_RULEBOOK.md

This is now the clearer operational rulebook. The older file remains here as the historical working baseline:

[Open the current playlist rules](rules.html)

Yes. The easiest way to understand it is:

Telecasting Planner
        ↓
Find the scheduled programs and time slots
        ↓
Media Path Catalog + current [private media root] files
        ↓
Resolve the exact media paths
        ↓
Measure durations and classify the media
        ↓
Add fillers, bumpers, and disclaimers
        ↓
Build the .ply file
        ↓
Validate everything

1. The Telecasting Planner creates the schedule skeleton

First I open the exact planner workbook requested by you.

For the recent build, that was:

the production network driveAW Team\Manish\Telecasting\Telecasting Planner\test_1.xlsx

I check:

• Does the requested date exist?
• Which worksheet contains it?
• What programs are in each time block?
• Which blocks are merged for 30, 60, or 90 minutes?
• Are there multiple programs inside one merged block?
• Are there open Fillers blocks?

For 3 September, the planner gave:

• 40 scheduled program items
• 2 open Fillers blocks
• Two merged blocks containing two programs each

The planner tells me what should play and approximately when. It does not always tell me the exact filename or filler selection.

2. What the Media Path Catalog does

ATHENSA_MEDIA_PATH_CATALOG.xlsx is a searchable reference database built from the real .ply samples.

It contains sheets such as:

• Episode Paths — observed episode paths
• Scheduled Meditations — observed full meditation paths
• Filler Paths — observed filler paths
• Program Folder Map — which folders have been observed for each program
• Filler Folder Map — which folders contain which filler types
• Needs Review — paths that require caution
• Every Use — every occurrence of every path in the sample playlists
• All Unique Paths — one row per unique observed path

For example, when the planner says:

AWBK-S13E26_Soul Connctions

the catalog helps identify that the normal source area is:

[private AWBK episode folder]

It also shows previously observed naming patterns, program classifications, and sometimes previous NOW/NEXT metadata.

Important limitation

The catalog is not a live playlist generator and it is not a complete scan of every file on the broadcast share.

It was built from observed .ply files. Therefore, I use it as a reference, but I still verify the current filesystem.

The real process is:

Catalog suggestion
        ↓
Check current [private media root] file
        ↓
Confirm exact filename and identity
        ↓
Measure current duration
        ↓
Allow it into the playlist manifest

So the catalog can suggest a path, but it cannot override the “file must exist now” rule.

3. How a path is resolved

For each planner program, I try to resolve one exact path.

Example: normal episode

Planner label:

AWBK-S13E26_Soul Connctions

The resolver searches the approved broadcast folders and finds:

[private AWBK episode folder]\13 Soul Connection_ENG\AWBK-S13E26_Soul Connctions.mp4

Then it checks:

• The file exists.
• The filename matches the planner label.
• It is not in BIN.
• Its duration can be read using ffprobe.

Example: date-specific Murli

Planner label:

Murli: Vidhi se Siddhi

That label is generic, so the exact date matters. For 3 September, the selected file was:

[private media root]\MURLI_vidhi se siddhi\the same-day Vidhi se Siddhi Murli

This is where the planner date and current media folder are both important.

Example: Asmita Didi's Song

Planner label:

Asmita Didi's Song

The actual media file is:

[private media root]\Amritvela Meditation\Amritvela_Asmita Didi_Song.mp4

The catalog and historical .ply samples show that this is treated as a scheduled full meditation-style program, not as an ordinary short song filler.

4. What happens if a path is missing?

I do not invent a path.

If I find:

• zero candidates, or
• multiple equally plausible candidates,

I stop and ask you something like:

I cannot uniquely resolve:
AWBK-S13E27_Example

Possible folder:
[private AWBK episode folder]

Please provide the exact media path.

The previous episode's folder may help me search, but it is only a search hint. It is not permission to silently select a different file.

5. How fillers are added

The planner's Fillers cell does not identify a particular filename. It means:

There is an open period that must be filled with approved filler material.

Approved filler sources include:

[private generic-filler folder]
[private media root]\Feel Good Melodies
[private short-filler folder]
[private bumper folder]

The builder can use:

• general filler videos;
• approved song videos;
• short meditation clips;
• Disclaimer;
• NOW/NEXT bumpers;
• Murli Saar when the correct daily file is known.

The filler solver checks the available gap and chooses real files whose durations fit.

If the gap is too short, filler can be omitted or shortened when appropriate. Fixed episodes and full meditation programs are not shortened just to preserve filler.

6. The BIN rule is applied several times

The BIN rule is not checked only once.

It is applied when:

1. Building the Media Path Catalog.
2. Scanning current media files.
3. Resolving planner labels.
4. Selecting fillers.
5. Building the .ply.
6. Validating the completed playlist.

Any path containing a folder named BIN is rejected.

For example, this can never be selected:

[private media root]\Feel Good Melodies\BIN\some-video.mp4

7. How the actual .ply is constructed

After resolving the planner programs, I create an internal manifest containing:

Planner time
Planner label
Exact media path
Duration
Program type
NOW metadata
NEXT metadata
Episode or meditation classification

Then the builder:

1. Places the fixed programs in planner order.
2. Keeps multi-line merged blocks sequential.
3. Adds NOW/NEXT bumpers where available and where they fit.
4. Adds Disclaimer where appropriate.
5. Adds approved filler into the remaining gaps.
6. Gives every item a unique LISTID.
7. Writes the observed ATHENSA .ply structure.
8. Marks the result as test-only.

The catalog itself does not write the .ply. It helps resolve and classify the media. The separate builder uses the verified manifest to write the actual playlist.

8. Final validation

Before I call the playlist complete, I validate:

• Does the .ply parse?
• Are all required headers present?
• Are all LISTID values unique?
• Are all media paths present?
• Are all durations positive?
• Do the 40 planner programs appear in the correct order?
• Is the total duration 24 hours when a full-day playlist is requested?
• Is there any BIN path?
• Were any paths unresolved?
• Were any bumpers omitted?
• Were any fillers shortened?
• Were any programs delayed because an earlier full program ran long?

For the 3 September test playlist, the verification found:

40 scheduled programs
306 total media items
306 unique LISTID values
0 missing media paths
0 BIN references
24-hour total

So, in one sentence:

The planner tells me what should play, the catalog helps me understand where and how that type of media is normally stored, the current broadcast folders prove the exact file exists, and the verified manifest—not the catalog alone—is used to build the .ply file.

Yes, I remember it.

The latest playlist was the planner-based 3 September test playlist, created from:

the production network driveAW Team\Manish\Telecasting\Telecasting Planner\test_1.xlsx

The file is:

[Open the research pack index](assets/documents/research-pack-readme.md)\ply-lab\generated\2026-09-03-test-planner.ply

It contains:

• 40 scheduled programs from the planner
• Fillers and available NOW/NEXT bumpers
• 306 total media items
• Exactly 24 hours
• 306 unique LISTID values
• 0 missing paths
• 0 BIN references

It is clearly marked:

TEST ONLY - 2026-09-03 PLANNER - DO NOT AIR

There was also an older format proxy playlist, but the one above is the actual planner-based 3 September test playlist.

The main missed pattern is service-block continuity—not simply “next playlist item” or “next planner cell.” Read-only review completed; both original .ply hashes match the comparison snapshot. Counts verified: 306 generated items, 214 final items, 40 programs each; 39 program paths unchanged.

G = generated item; F = operator-final item.

Confirmed differences

• NEXT must look beyond consecutive items of the same service.
• F40–42 (Amritvela_Asmita Didi_Song.mp4, Amritvela_Suraj Bhai_Experiencing God's Powers.mp4, Avyakt Baapdada_Murli 2019-12-15_p2.mp4) all advertise WORDS OF WISDOM. This block crosses the 03:30 and 04:00 planner entries.
• F197–198, AWBK-S02E34_Being Love.mp4 and AWBK-S02E35_Being Love.mp4, both advertise KARMA, DESTINY & CHOICE; they run consecutively without another bumper/disclaimer package. Separate 21:00/21:30 planner slots therefore do not necessarily mean separate presentation blocks.

• Physical bumpers follow the same logic: G43 Amritvela NEXT.mp4 → F38 Words of Wisdom NEXT.mp4, and G227 Evening Meditation NEXT.mp4 → F170 AWBK NEXT.mp4. The latter fixes a self-teaser even though the generated evening-meditation metadata already advertised AWBK correctly.

• Other stale NEXT corrections are schedule-dependent, not title substitutions to learn permanently:

• Presentation order matters. Final’s ordinary complete package is NEXT → NOW → Disclaimer.mp4 → episode. The generator omitted episode-head disclaimers at G1, G4, G49, G72 and G239, restored before corresponding F5, F9, F47, F65 and F183. Conversely, final removes disclaimers before full-meditation block heads F40/F172. Final has 34 disclaimers for 35 episodes; the exception is the continuous second AWBK episode F198, not an obvious omission.

• Vidhi’s title animation is a distinct missing element. Final inserts Vidhi se Siddhi Title Animation.mp4 at F73, F115 and F157, after the disclaimer and before the same-day Vidhi se Siddhi Murli at F74/F116/F158. All three animations are absent from generated.

• Final also suppresses isolated NEXT bumpers. Generated Parivartan NEXT.mp4 before KDC/Mindful Moments (G29/G166), Ruhrihan NEXT_1.mp4 before Mindful Moments (G213) and jewels of knowlege NEXT.mp4 before KDC (G289) disappear. Final has no NEXT-only pre-program package. This is a consistent observation, not yet proof of a universal “omit NEXT when NOW unavailable” rule.

Scheduling patterns—not rigid new rules

• 18 Thursday WISDOM Meditation_*.mp4 hourly clips are entirely missing from generated. Final generally places them around the hour before presentation bumpers. It retains late clips at F154, WISDOM Meditation_Student.mp4, 17:01:56, and F179, WISDOM Meditation_Conversation.mp4, 20:00:33. Thus “an overrun always cancels hourly meditation” would be wrong.
• No short hourly clip appears at 04, 05, 07, 09, 19 or 22. Long services explain several gaps; Murli Saar occupies the early 05/07 transitions. These omissions are not sufficient evidence of errors or a permanent exemption list.
• 3 September_Murli Saar.mp4 appears six times, at F37/F43/F63/F66/F97/F169: approximately 03:28, 05:01, 07:00, 07:49, 10:52 and 18:28. Generated has none. Placement is not exclusively immediately before bumpers: F66/F97 precede further song/filler/hourly content.

Operator-final issues to retain for review

• Confirmed introduced typo: F16, MOC-S03E06_Charlie Hogg_Kim Cunio.mp4, has NEXT AWAKENNG WITH BRAHMA KUMARIS; generated spelling was correct.
• Confirmed trailing space: F140, AWBK-S09E02_Madhuban Classes.mp4, has NEXT LET'S CHANGE THE WORLD. Whether this affects rendering/matching is unverified.
• Four nonzero #TC values deserve attention: F53 Jitna Yaad Karu_Arushi Imamadar.mp4 and F201 Empowering The Self_Moments & Memories.mov: 465660.04167; F147 Main Jagmagati Mastakmani.mp4 and F184 Vishwa NavNirman_BK Damini.mp4: 524100.04000. These contradict any blanket “all TC values are zero” assumption; their playback significance is unresolved, not a confirmed scheduling fault.
• F52 changes MYB-002_Stretching and Tapping Exercises_BK Sujata_P1.mp4 to MYB-001_Stretching and Tapping Exercises_BK Sujata_P1.mp4, retaining the same declared duration. Record this as an operator substitution, not an automatic planner correction.
• Final’s cumulative end is 24:00:00.13251. That small deviation is not itself evidence of a fault. F211’s final NEXT announcement of AWBK needs the following day’s schedule to validate.

No files created or modified; no media probing, vendor execution or live actions performed.

Yes—the comparison makes the missing rules much clearer. The main programme structure was largely correct; the biggest problems were filler selection, missing supporting clips, and programme-announcement metadata.

I compared every item and checked the referenced media. Both original playlists are unchanged.

39 of the 40 programme paths match. The remaining filename change is explained below.

1. Large gaps need longer content—not many short fillers

Your new rule addresses a real weakness in my builder.

For example:

• Between the 12:30 and 13:30 programmes: mine inserted 28 supporting items; yours uses 7.
• After the second Being Love episode, before 22:30: mine inserted 26 items; yours uses 6.

Your final uses longer material such as:

• What is YOGA_BK Shivani.mp4 — 7:18.20
• fop_CH_v002.mp4 — 12:19.88
• Jhilmil Sitare Ban Kar_Kavita Krishnamurti_After 8pm.mp4 — 8:12.04

Rule recorded: use suitable longer fillers or Feel Good Melodies songs for large gaps, then balance the remaining time with shorter fillers.

I also incorrectly restricted the explicit Fillers blocks to the general Fillers folder. A planner cell called “Fillers” describes the slot’s purpose—not the only folder allowed.

The final also shows much better variety. My version repeated one short filler 38 times. That needs a repetition check, not just a duration check.

2. I created some technically unsuitable filler fragments

This was the clearest technical error.

My builder shortened a 15-second filler to whatever tiny remainder was left. It produced 13 entries shorter than one second, including:

• 0.014 seconds
• 0.018 seconds

That source runs at 25 fps, so one frame lasts 0.040 seconds. Those two entries are shorter than a single source frame.

Correction: don’t force an exact total by inserting tiny fragments or arbitrarily cutting speech or songs. Select useful whole clips first; any trimming needs suitable material, a safe edit point, and valid frame boundaries.

My earlier “all checks passed” statement was too broad. Those checks verified structure and arithmetic, but missed this operational problem.

3. I left out recurring and programme-specific content

Your final restores three important elements:

These should be planned deliberately—not treated as content that might happen to be selected randomly.

However, 18 meditation clips and six Murli Saar placements are observations from this day, not universal daily quotas.

4. NEXT must be rebuilt for the current schedule

I found eight meaningful NEXT corrections. My builder sometimes copied an old episode template’s NEXT value instead of recalculating it.

Examples:

There’s another important pattern:

NEXT announces the next distinct programme after the current continuous programme block—not necessarily the next media file.

For example:

• The Amritvela files all announce Words of Wisdom next.
• The two consecutive Being Love episodes announce Karma, Destiny & Choice next.
• Your Being Love episodes play back-to-back without another bumper/disclaimer package between them.

I should reuse the format of historical metadata, not its old scheduling information.

5. Episode starts and introduction-package starts are different

My version began the first episode exactly at midnight.

Your final begins with:

Short Wisdom meditation
→ Ruh Rihaan NEXT
→ AWBK NOW
→ Disclaimer
→ AWBK episode

The episode consequently starts at 00:02:14.966.

So I was treating some planner anchors too rigidly. The scheduling model needs to distinguish:

• the intended slot boundary;
• the meditation/introduction package;
• the actual episode start.

Your final also uses different packages for different content: full meditations don’t receive the same Disclaimer treatment as episode introductions, and continuous same-programme files don’t automatically get repeated introductions.

These are strong patterns in this final—not permission to apply one fixed delay to every slot.

6. Some durations should come from video—not the longer audio/container tail

Fresh media probes confirmed this.

For P-042:

• My duration: 1322.794 seconds
• Your duration: 1322.760 seconds
• Actual video-stream duration: 1322.760 seconds

The extra time was in the audio/container duration. Similar differences occur in WW-001 and P-033.

Correction: record video duration, frame rate, and audio/container duration separately, then use the verified playout-duration convention. ffprobe format=duration alone isn’t sufficient.

7. One programme filename changed

At 05:30:

My version and saved planner:
MYB-002_Stretching and Tapping  Exercises_BK Sujata_P1.mp4

Your final:
MYB-001_Stretching and Tapping  Exercises_BK Sujata_P1.mp4

The exact MYB-002 path is missing now, while your final’s MYB-001 path exists. The saved planner still says MYB-002.

I’ve recorded this as a date-specific operator correction, not a general rule to replace episode numbers. The files alone don’t establish whether this was a rename or a substitution.

Other technical details

• The attachment is Windows-1252, not UTF-8. The warning comes from a curly apostrophe; the file decoded losslessly.
• My supporting paths contained unnecessarily doubled backslashes. Windows tolerated them, but export should preserve normal verified path strings.
• Your final contains some nonzero #TC values. These need preservation and verified interpretation—not an assumption that every item uses zero.
• Your stored durations total 24:00:00.13251. That small difference is evidence from this file, not automatically a new allowed tolerance.

What I’ve saved

I updated the rulebook and the reusable workflow notes, separating confirmed rules, observed patterns, and unresolved decisions.

One clarification: the old generator used a fixed filler list, not a direct automated lookup in ATHENSA_MEDIA_PATH_CATALOG.xlsx. Updating the rulebook does not repair that code. I have not changed the generator or regenerated either playlist during this comparison.

Detailed comparison workbook:

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/comparisons/2026-09-03-operator-final/ATHENSA_2026-09-03_COMPARISON.xlsx

Full findings and evidence:

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/comparisons/2026-09-03-operator-final/REVIEW.md

Updated rulebook:

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ATHENSA_PLAYLIST_RULEBOOK.md

The independent review confirmed the main findings and added two useful checks, now recorded in the report and rulebook:

• Missing from my bumper map doesn’t mean missing from your folder. My map omitted Words of Wisdom bumpers even though matching files were available.
• The last programme’s NEXT must be checked against the following day’s planner, not assumed to repeat today’s opening programme. I checked 4 September: it starts with AWBK-S13E27_Soul Connctions, so your final AWBK announcement agrees with that planner.

Neither playlist was modified.

By “my map,” I meant a lookup list inside the code I wrote—not a map you created. Sorry, that wording was unclear.

It connects each programme name to its NOW/NEXT bumper files. For example:

Programme: Awakening with Brahma Kumaris
NOW file:  [private bumper folder]\AWBK NOW.mp4
NEXT file: [private bumper folder]\AWBK NEXT.mp4

The code calls that list BUMPER_PATHS.

I left Words of Wisdom out of that list. Consequently, the builder treated its bumpers as unavailable—even though the files existed in your folder.

That was my coding omission, not a problem with your files.

This list is also separate from ATHENSA_MEDIA_PATH_CATALOG.xlsx. The catalog is the broader media reference workbook; BUMPER_PATHS was a smaller, hard-coded list used by the playlist builder.

Currently, I’m using ATHENSA_MEDIA_PATH_CATALOG.xlsx as a reference workbook—not as a direct input to the playlist generator. My earlier explanation made it sound more integrated than it actually is. That was misleading.

What I use the catalog for

It lets me inspect: - Known episode and filler paths from previous playlists. - Which folders contain each programme. - Whether an item was classified as an episode, full meditation, or filler. - Where a file appeared previously. - Its recorded existence status—which still needs a fresh check.

What actually happened in the 3 September build

The scripts followed this flow:

Telecasting Planner
        ↓
Search [private media root] for matching programme files
        ↓
Check file existence and measure durations
        ↓
Read previous .ply files for metadata templates
        ↓
Create a resolved programme list
        ↓
Add fillers and bumpers from hard-coded lists
        ↓
Generate the test .ply

The Excel catalog was not read by those scripts. Editing a path or adding a filler in that workbook would therefore not automatically change the generated playlist.

What the catalog-driven approach should be

Planner programme
        ↓
Look up its exact path in the catalog
        ↓
Verify the file on disk
        ↓
If absent from the catalog, search the approved folder
        ↓
If still unresolved or ambiguous, ask you

For fillers, the builder should use a verified collection with durations and restrictions, rather than the small fixed list I used.

So the gap is clear: I created the catalog, but I hadn’t connected it to the generator. That integration is still needed.

The generator is the Python code I wrote that assembles the playlist and saves it as a .ply file. It isn’t ATHENSA itself—it prepares a file for ATHENSA.

Think of the parts like this:

Would connecting the catalog help?

Yes—it would make the workflow more consistent and easier to maintain. Right now, information is duplicated: the catalog contains media information, while the generator has its own smaller, hard-coded lists. Those lists can miss files that are available.

Connecting them would give us this flow:

Read the requested date from the planner
                    ↓
Look up programme paths in the catalog
                    ↓
Verify the files still exist and check their durations
                    ↓
Calculate the gaps between programmes
                    ↓
Select suitable fillers from the catalog
                    ↓
Apply the scheduling and presentation rules
                    ↓
Write and validate the .ply

Example: filling a large gap

Instead of selecting from a small list embedded in the code, the generator could look through the catalog for:

• Longer approved fillers or Feel Good Melodies songs.
• Shorter clips to balance the remaining time.
• Content suitable for that time of day.
• Files that haven’t already been repeated too much.
• No content from BIN.

One important condition

Connecting the files alone isn’t enough. The catalog also needs reliable selection information—particularly usable durations, approval status, time restrictions, and recent usage. Some of that information needs to be added or refreshed.

The generator must still check the actual files on disk. A catalog entry can become outdated if a file is renamed, moved, or removed.

In short: yes, connecting them is the right improvement. The catalog should supply the media information, rather than the generator maintaining a separate little list of its own. That connection has not been implemented yet.

You’re right: a catalog built only from previous playlists cannot cover everything on the drive. It needs to become a current media inventory, not just a record of past usage.

1. Have all episodes and fillers been mapped?

No—not yet.

The current Excel catalog contains 893 unique paths collected from previous playlists. It is not a complete, maintained inventory of the broadcast drive.

During our comparison, it contained only 83 of the 132 distinct paths in your final playlist. That demonstrates the gap.

Although I scanned the drive while resolving the September programmes, that scan was not fully incorporated into the Excel catalog.

How new episodes and unused fillers should enter the workflow

The improved process should be:

Scan the approved media folders, excluding BIN
                       ↓
Discover new files and detect missing/changed files
                       ↓
Identify their programme/type and measure their durations
                       ↓
Add or update their catalog records
                       ↓
Use verified, eligible records for playlist construction

Two distinctions matter:

• New episode: the planner determines whether it should be scheduled. Its presence on the drive alone does not authorize adding it to the day.
• New filler: it becomes a selection candidate once its classification, suitability and approval status are established. A file simply existing does not automatically make it approved.

If a planner label matches one verified file unambiguously, it can be resolved. If it remains missing or ambiguous, I ask you.

Previous playlists should provide naming and presentation evidence—not limit the available media library.

2. How should durations be measured moving forward?

The correction is to stop treating the file’s overall container duration as the only duration.

For each video, the proposed inventory should retain:

For example, we verified:

P-042 container/audio duration: 1322.794 seconds
P-042 video duration:           1322.760 seconds
Your final playlist uses:       1322.760 seconds

That difference is not cutting programme content; it avoids scheduling the longer audio/container tail as though it were additional video.

The procedure should therefore be:

1. Probe video and audio information separately.
2. Use the verified video/playout-duration convention.
3. Flag unexplained differences instead of silently choosing a value.
4. Re-measure files when their size or modification time changes.
5. Check again before export that the selected assets are still the verified versions.

For mixed or variable frame rates, simple frame-count division or rounding everything to 25 fps is not sufficient. Uncertain cases need closer inspection and, where necessary, ATHENSA import verification.

And no more tiny filler fragments to force an exact sum. Gap balancing should prefer complete clips; partial trims need appropriate material and approved, valid edit points.

This duration approach is documented, but the old generator has not yet been updated to implement it.

3. Can you edit the Excel catalog?

Yes—you can open and edit it. But the current workbook is not yet safe as a permanent operator-editing interface.

I checked its structure:

• The main path and usage sheets are not protected.
• The catalog-generation script creates a new workbook and saves over the existing catalog.
• Therefore, a regeneration can overwrite your manual changes.
• The same asset appears in multiple derived sheets; editing one does not automatically update the others.
• Your edits currently do not feed into the playlist generator.

For now, make a separate editable copy rather than relying on changes to the generated original. Historical counts, source-playlist records and measured durations should remain evidence—not manually adjusted values used to make a slot fit.

The better editable design

Separate machine-discovered facts from your decisions:

Your corrections should be stored separately and preserved during refreshes. The generator would then use the latest verified inventory plus your explicit overrides, while keeping BIN excluded.

So the right direction is: complete drive inventory → preserved operator edits → connected generator → stronger validation. The current workbook is only the historical-reference part of that system.

Yes—the drive-based path mapping is complete for the programme folders scanned, including files that never appeared in previous playlists.

What’s mapped

I scanned 32 folders, including their subfolders. 4,198 episode paths were absent from the old catalog.

Examples from the new episode mapping:

Download the new Excel inventory

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/episode-inventory/2026-09-09_212605/ATHENSA_EPISODE_PATH_INVENTORY.xlsx

Start with Episode Paths. Each row contains the exact path, filename, programme folder, recognizable episode ID, file size, modification time, and classification evidence.

Needs Review contains mapped files from mixed-content folders such as Festivals, Event and Film. Their paths are captured, but I haven’t guessed that every file is an episode.

Verification and limits

• A second scan matched the inventory; no paths disappeared or changed during verification.
• 18 BIN directories were pruned without entering them.
• Your original ATHENSA_MEDIA_PATH_CATALOG.xlsx is unchanged.
• Dedicated filler/song/bumper folders were excluded from this episode-mapping task.
• Durations were not measured in this pass.
• New files are marked as candidates where classification is based only on their folder. Mapping does not mean broadcast approval.

This is a fresh inventory snapshot; it is not yet connected to the playlist generator.

“Needs Review” means the paths are mapped, but their content type or permitted use hasn’t been confirmed. It does not mean the files are damaged or rejected.

The label was broad: most were flagged because their folders weren’t in my established programme-folder list—not because I found something wrong with each video.

What is in that sheet?

For example, AGE-S02E01_USA Event.mp4 and EcoShanti_S01E01_BK Shrinidhi_David Fletcher.mp4 look like clearly named episodes. They were flagged because I hadn’t established the folder’s classification—not because those filenames were ambiguous.

There are also two case-only filename collisions within Festivals: Dadi at UN.mp4 and dadi at UN.mp4. Those need an individual check.

How you can review them

Start with folders or series—not thousands of individual videos.

1. Open the workbook’s Needs Review sheet

Filter the Programme folder column, then use Subfolder to narrow larger folders such as Festivals.

Look at: - Filename - Exact path - Classification basis - Historical classification - Case-only path collision

2. Give a folder-level decision where appropriate

For example, you could tell me:

“All numbered files in Ecoshanti are episodes. Use them only when the planner schedules them.”

Or:

“Films are scheduled programmes, not automatically available as fillers.”

Those are examples—not assumptions I’ve applied.

A single decision can classify a whole series. Exceptions can then be handled separately.

3. Review mixed folders by subfolder

For Festivals, avoid approving the entire folder in one step. Different subfolders may contain different types of content and restrictions.

Useful decisions are:

Classification and approval are separate: calling something an episode does not automatically schedule it; calling something a filler does not automatically approve it for every gap.

Can you record decisions in Excel?

Yes. In a separate review copy, add columns such as:

Reviewed type
Permitted use
Restrictions
Reviewer notes

Keep Exact path and the original evidence columns unchanged. Your decisions currently won’t feed the generator automatically, so the reviewed copy needs to be imported or reconciled explicitly.

The easiest starting point is to confirm the roles of Awakening Global Event, Ecoshanti, Healer Within, and Legacy of Love. The much larger Festivals collection can then be reviewed by subfolder.

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/episode-inventory/2026-09-09_212605/ATHENSA_EPISODE_PATH_INVENTORY.xlsx

All 18 correction annotations are verified and recorded as mandatory requirements. Six evidence checks passed; the generator itself is not yet repaired. The separate full-playlist review is still pending, and no newly inferred rules have been applied.

Review completed

I analyzed the supplied files:

• S:\Hermes\attachments\correction.txt
• S:\Hermes\attachments\2026-09-10.ply

Explicit corrections

All 18 correction annotations were verified against the reviewed generated playlist. The six evidence checks passed, including:

• exact LISTID matching;
• source-file hash preservation;
• correction transcription;
• playlist row counts and duration totals;
• current asset probes;
• unchanged source files.

The corrections have been recorded as mandatory requirements in:

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

They cover:

• missing NOW/NEXT handling;
• no NEXT when NOW is unavailable;
• filler-family adjacency;
• Murli Saar placement windows and rejected placements;
• permitted 1-Min Meditation hours;
• meditation maximum delay of 30 seconds;
• episode maximum delay of 120 seconds;
• the continuous 21:00–22:00 episode segment;
• disclaimer placement before that segment;
• the 22:00 goodnight song;
• missing presentation assets.

Important: recording the rules does not repair the generator. The existing 3 September and 10 September builders still have known compliance defects and have not been used as compliant schedulers.

Manual playlist findings

The manual playlist contains:

• 208 media items;
• 208 unique LISTIDs;
• 40 planner-matched programmes;
• 35 episodes;
• 16 short meditations;
• 5 full meditations;
• 17 songs;
• 41 general fillers;
• 34 disclaimers;
• 25 NEXT bumpers;
• 30 NOW bumpers;
• 3 Vidhi title animations;
• 1 film;
• 1 goodnight song.

The playlist totals 24:00:00.87608 using its stored scheduling durations. It also crosses two nominal planner filler boundaries, around 13:00 and 22:00. Therefore, it is useful evidence, but not proof of exact planner-timing compliance or ATHENSA acceptance.

New rules requiring your approval

These are saved as proposals only:

[Open the research pack index](assets/documents/research-pack-readme.md)\ply-lab\comparisons\2026-09-10-operator-corrections\MANUAL_PLAYLIST_NEW_RULE_PROPOSALS.md

I have not applied P01–P06. The approval prompt timed out without a selection.

Please reply in this format:

Approve: P01, P02, P03
Hold: P04, P06
Reject: P05

Only after your approval will I implement the selected rules in the research-only generator and create regression tests. No live ATHENSA software, live playlist folder, or broadcast system will be touched.

Created the 10 September research-only playlist using approved rules P01–P06.

Playlist:

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-10-approved-rules-20260912/2026-09-10-approved-rules.ply

Reports:

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-10-approved-rules-20260912/README.md

MEDIA:C:/Users/Awakening_PC2/Documents/Athensa-Hermes-Research/ply-lab/generated/2026-09-10-approved-rules-20260912/validation.json

Verified

• 40 programmes in exact planner order.
• 206 total items.
• 206 unique LISTID values.
• All media paths exist.
• All selected media use complete durations and zero in-points.
• Zero BIN paths.
• Zero repeated filler paths.
• Zero adjacent filler-family violations.
• NEXT is never included without an immediately paired NOW.
• All 16 permitted meditation-hour slots are represented.
• 22:00 meditation was replaced with Paramatma Ki Godh Mein_Goodnight Song.mp4.
• The 21:00 AWBK programmes are contiguous with no files between them.
• Parser validation passed before and after saving/readback.

Important timing exceptions

This is an offline-validated candidate, not a broadcast-ready playlist:

• Total duration: 23:59:59.70261, which is 0.29739 seconds short of 24 hours.
• Several episodes exceed the approved 120-second delay because the full media and presentation packages cannot fit without trimming.
• The 10:00 meditation starts approximately 269.43 seconds late because the preceding intact programme overruns.
• The 20:00 meditation starts approximately 31.87 seconds late, slightly beyond the 30-second limit.
• The goodnight song starts at 22:01:09.69061, approximately 69.69 seconds late.
• The required NEXT for the 22:30 KDC programme could not be added because no exact KDC NEXT asset was available. No incorrect bumper was guessed or substituted.

No live ATHENSA software was run, and the playlist was not imported, staged, deployed, or broadcast.

I can’t generate the 14 September playlist yet because the authoritative planner currently has no programme entries for 14 September 2026.

Verified read-only in:

• the production network driveAW Team\Manish\Telecasting\Telecasting Planner\Telecasting Planner - Sep 2026.xlsx
• the production network driveAW Team\Manish\Telecasting\Telecasting Planner\test_1.xlsx
• September_2026 and Copy of September_2026 sheets

The 14 September date column exists, but it is completely empty. Since the planner controls programme order, slots, and placements, I won’t invent a schedule or substitute another date.

Please provide the completed 14 September planner, or tell me which authoritative schedule should be used.

Here are the files currently being used:

1. New ATHENSA Playlist Rulebook
   Download ATHENSA_PLAYLIST_RULEBOOK.md

2. ATHENSA Media Path Mapping Catalog
   Download ATHENSA_MEDIA_PATH_CATALOG.xlsx

The rulebook is the canonical current rules document, including approved rules P01–P06, planner precedence, exact-path requirements, filler selection rules, BIN exclusions, and offline .ply validation requirements.

The Excel catalog is the reference mapping file containing the individual media paths plus programme and filler folder maps. It excludes BIN content. It remains a reference catalog rather than the sole durable source for manual approvals or overrides.