2 Commits
Author SHA1 Message Date
Waters ChurchandClaude Fable 5.1 c73d0a3aac PCO Plan 1.6.0: the message document is matched by the plan's own name
The current item followed the live ProPresenter document by title alone,
and a sermon's document is named after the sermon — Waters names them
"YYMMDD Series Title - Part #" — never after its plan item. So the last
song stayed current through the whole message: North Attleboro on 20 Sept
spent 65 minutes on one song in two of its three services.

A live document that reads like the plan itself — its date code, series
title and part — now lands on the plan's message item: an item titled
Message, Sermon or Teaching, else the first item under such a header. A
date code naming another day is a firm no, so last week's sermon stays
unplaced. Position in the ProPresenter playlist breaks a tie between
equal names, only while the playlist mirrors the plan item for item, and
never places a document on its own.

The log now says what it never said: every feed drop and reconnect, which
item the message document will land on, what placed each item and how,
and a live document that is not in the plan.

matching.test.js: 27 checks built from both campuses' real 27 Sept plans
and ProPresenter playlists.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-22 13:06:53 -04:00
Waters ChurchandClaude Fable 5.1 48526934bb pco-plan: per-service timing, ProPresenter cues, timers for the Timers module
The service clock now belongs to one service at a time: a plan's services
take turns by window (the next one takes over pre-roll before its start,
once the previous one has ended or was due to end), and moving into the
next window resets the service elapsed clock, the item timing and the
countdown. A service starts at its scheduled time or, under the new
"Service timing" admin group, when a chosen ProPresenter document goes
live (scheduled time as the failsafe); it ends when the chosen end
document goes live, or at the next service / plan end + 60 min.

The pure logic lives in service-timing.js and matching.js (cue documents
are matched like plan items, with a stricter 0.75 bar so the pre-service
loop never ends a service) with service-timing.test.js covering windows,
precedence and failsafes. GET /timers and /timers/stream offer the
service, current-item and countdown timers per the module guide;
GET /documents lists the documents the Now/Next feed has shown or listed
for the new selects. Loopback calls use shell.port, with the old
proddash.json guess only when the shell hands no port.

Manifest: 1.4.0, proddash >=1.4.0, provides ["timers"]; Client ID
wording, shorter labels, group help tightened, field help trimmed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-13 12:58:12 -04:00