TECHNICAL TASK
Development of a Digital Signage system for a network of advertising screens
1. General description of the system
The system is designed for remote management of media content (video, images) on a network of televisions running Android TV.
Architecture:
- Backend / Control Panel (Admin Panel): PHP (Laravel / Yii2 or pure PHP) + MySQL.
- Frontend (Player on TV): HTML5 / JavaScript (Single Page Application), which runs on TV in full-screen mode via the Fully Kiosk Browser app.
2. Functional requirements: Control Panel (Admin Panel on PHP)
2.1. Screen (Television) Management
- Ability to add/remove screens in the system.
- Each screen is assigned: Name (geo-point), unique ID (device_token), and status (Online/Offline).
- Monitoring (Ping): Displaying the TV status in real-time. If the TV has not sent requests for more than 5 minutes, color its status red (Offline).
2.2. Content Management (Media Library)
- Uploading files (video, images) to the server.
- Deleting files (with automatic deletion of the physical file from the server).
- Ability to view (and modify) on which screens each individual media file is broadcasted.
- Setting the playback order of files.
2.3. Server API (for communication with TV)
Implement REST API (JSON):
- POST /api/ping — receives its ID from the TV, records the last activity time (for Online status), and returns the current playlist version.
- GET /api/file/device_token — returns the current JSON array with links to media files, their order, and display time settings.
3. Functional requirements: Client Player (HTML5/JS on TV)
The player is a web page that is opened on the TV. The main task of the client is autonomy.
3.1. Caching and Synchronization (Offline Operation)
- Upon startup, the player requests the playlist via the API.
- Local Storage: All files from the playlist (video/images) must be loaded into the internal memory of the browser (using Cache API or IndexedDB). Streaming (playing directly from the internet) is prohibited.
- Synchronization:
- If new content is added on the server, the player loads it in the background without interrupting the current display. After loading is complete, it adds it to the broadcast.
- If content is deleted on the server, the player must remove it from the local TV cache to avoid filling the device's memory.
- Offline Mode: In the complete absence of the internet, the player endlessly loops the last successfully loaded playlist.
3.2. Playback and Rotation
- Cyclic playback of content <video> and <img> according to the order set in the admin panel.
- For images, the display duration in seconds must be set (default 10 sec).
- Transitions between videos must be smooth, without black screens and noticeable page reloads.
3.3. Logging and Error Control (Failure Protection)
- Handling Corrupted Files: If a video file is corrupted and cannot be played, the player must skip it and turn on the next one in order, rather than hanging on a black screen.
- Show Logs (Analytics): The player must record in local memory the fact of each successful playback of a video. When the internet is available, this data is sent in batches to the server (POST /api/logs), so that statistics can be viewed in the admin panel: "Video A on TV #3 was shown 450 times in a day and 2365 times in total".
4. Optimization Requirements for Android TV
- The player interface must not contain any control elements (cursors, scroll bars, buttons). Only clean content on the full screen.
- JS code must be optimized for memory (timely clearing unused DOM elements and object URLs), as budget televisions have strict limitations on RAM and may crash the tab due to memory leaks after 12-24 hours of continuous operation.
