The idea
Provide a shared-screen experience for a hall or common room, with scheduled content and clearly separated operator permissions. V1 is a kiosk application on a supported player connected to a TV, not a new television operating system. Pilot one building and two content owners before extending to multiple locations.
The connection
A television becomes a common-room interface. The interesting problem is balancing distinct content owners with one coherent, reliable experience for everyone in the space.
How it could work
Separate content administration from playback. The player downloads a versioned manifest and verified assets, then continues using the last good set during an outage. A new manifest becomes active only when its required assets are available. A failed upload must not blank the screen.
Multi-tenancy is a data and permission boundary, not just a filter in the interface. Every content, schedule and device request must be checked against its tenant on the server. A paired device receives only the content authorised for that location. Public-screen pairing should not expose an administrator's long-lived credentials.
What would prove it
Create two test tenants with separate content and operators. Attempt cross-tenant content reads, edits, scheduling and device pairing. Run the player offline for 24 hours, interrupt an update midway and test schedule boundaries around local midnight. Fill its cache deliberately and restart it during playback.
Proposed gate: all cross-tenant attempts are denied; the player keeps a valid cached programme during outage; partial updates never replace the last-good manifest; expired content disappears according to the documented offline policy; restart returns to playback without a login prompt. Exact media performance targets depend on the chosen player and codecs.
The path to a complete build
- Inspect the existing HallOS code and define one pilot location and role matrix.
- Implement permission checks and test them before broad content administration.
- Build manifest-based playback and a reliable cache/update process.
- Add scheduling and a minimal health view; run the outage tests.
- Pilot with real operators and publish a recovery procedure for a replacement player.
Open the engineering notebook
Components, interfaces and calculations
Pilot hardware: an existing TV, supported compact player, reliable power/network connection and a remote or control method. Software inputs: a tenant model, roles, content types, scheduling rules, asset cache and device health record. Choose a narrow content set—images, short video and announcements—before allowing arbitrary websites.
The working flow is draft → preview → approve → schedule → download → activate. Include start/end time and timezone explicitly. Device status should report current manifest revision, last successful contact and any missing assets without exposing private tenant content to other tenants.
Scope and development questions
Allow 6–10 sessions for a restricted pilot after code review. Cost player hardware, media storage, bandwidth and operator support separately. Resolve whether tenants are buildings, organisations or individual residents, who approves public content and how long cached announcements remain valid. No existing HallOS implementation was audited as part of this plan.
Reference basis
This is a proposed application architecture derived from the published HallOS concept. The existing source and chosen player specifications are required before selecting implementation-specific libraries or claiming a supported codec/performance profile.