Content, local data and operations

Overview and explanation

The device prepares content locally. Playback of prepared media is therefore separate from immediate network availability. Operational monitoring, reports and updates use their own communication paths.

Preparing and activating content

1. Load definitions: Runtime loads new content definitions separately from the layers currently in use.
2. Download resources: It downloads the required resources.
3. Activate the new layer: It confirms a new layer after successful preparation.

Preparation is retried on failure. This supports continued use of the last prepared content.

A successful download or non-zero file size is not cryptographic verification of the content. A file is described as verified by signature or hash only where that specific path performs the corresponding check.

For the procedure, see Content distribution and offline operation

Connection loss and fallback content

• Local playback: If connectivity is lost, available local media can continue playing according to the valid schedule.
• New changes and remote administration: The outage also affects new configurations, files, remote administration and live data services.
• Web and mobile interaction: An embedded website or interactive mobile service may not work offline merely because local video playback continues.

Selecting the primary visual when a dynamic condition does not match is a different mechanism from the default content used for an empty or invalid schedule. Both require appropriate configuration.

For the procedure, see Device playlist check

What reports represent

• Operational reports: The player produces operational reports about the application and system, storage, network, versions and available diagnostics. The values available depend on the platform and hardware.
• Aggregate playback counts: Playback records originate in the playback application. The reviewed path puts items into a local queue and then groups them by campaign, visual and resource into aggregate counts. These aggregates are sent to the reporting service through Connector and the balancer.
• Report transmission: Local and server queues support transmission over intermittent connections. Their existence does not establish guaranteed exactly-once delivery, complete crash tolerance or confirmation of every write to the destination database.

This format is not a complete chronological export of each advertisement with its exact duration, outcome and immutable file version.

A player record is also not independent proof of the physical light output of an LED screen. Previews, aggregate reports and physical measurements are therefore treated separately.

For the procedure, see Device monitoring

For the procedure, see Campaign report

Updates and maintenance

1. Version and channel: Updater retrieves the available versions and selects the stable or beta channel.
2. Package download: It downloads the package for an application with a newer version available.
3. Version reporting: It reports the version to the portal before switching the active file and restarting the service.
4. Application switch: It switches the active file to the downloaded version and writes the version number.
5. Service restart: It requests a restart of the corresponding system service. The earlier version report does not, by itself, confirm that the new application started successfully.

• Player applications: This mechanism updates the player applications.
• Ubuntu and dependencies: Ubuntu, the display environment and dependencies have separate update lifecycles.

Verification of digital package signatures and automatic rollback after a failed start were not established in the reviewed path.

Data, backups and service conditions

• Local data: The device stores media, configuration, working databases, caches and logs.
• Server data: Servers store definitions, media and reporting data according to the function of each service.
• Backup and recovery: The source materials include daily and monthly backup procedures for database storage and files. These procedures alone do not confirm the current schedule, successful backups, database restore consistency or achieved RPO and RTO.
• Service conditions: Data locations, retention periods, recovery parameters, service availability, support response and recovery times, and migration scope form part of the service’s operating conditions. This technical description does not assign unsubstantiated numerical commitments to them.

Removing unused local resources is not equivalent to a customer archive retention policy.