Firmware upgrades keep SpinetiX players secure, stable, and feature-current. SpinetiX DSOS firmware updates include security patches, performance improvements, new feature support, and bug fixes. A well-planned firmware upgrade procedure minimizes downtime, avoids surprises, and ensures smooth rollback if issues arise. The key principle: never update all players at once — always use staged rollout.
Upgrade Workflow
Step 1: Pre-Upgrade Assessment
Before upgrading, review the firmware release notes. Identify: new features, deprecated features, known issues, and compatibility requirements. Check if your content projects use any deprecated features that the new firmware removes. Verify that your Elementi version is compatible with the new firmware.
Step 2: Lab Testing
Update one test player in a controlled environment. Verify: boot time, content rendering, data feed connectivity, API functionality, and display output. Run the test player for 24 hours to catch any stability issues.
Step 3: Staged Rollout
Update a small group (5–10% of fleet) — typically one per location or one per content type. Monitor for 24–48 hours. Check: player stability, content rendering accuracy, data feed connectivity, and network behaviour. If no issues, proceed to full fleet.
Step 4: Fleet Rollout
With Arya, select the remaining player groups and apply the firmware update. Players download, install, and reboot automatically. Schedule updates during off-hours (nights, weekends) to minimize visible downtime. Each player is offline for 2–5 minutes during the reboot.
Step 5: Post-Upgrade Verification
After fleet-wide rollout, verify: all players online in Arya dashboard, firmware version consistent across fleet, content rendering correct (screenshot verification), and no error logs. Document the upgrade in your maintenance log.
Update Methods
| Method | Scope | Access | Best For |
|---|---|---|---|
| Arya cloud | Fleet / group | Web browser | Large fleet, multi-site |
| Player web interface | Single player | Browser (LAN) | Lab testing, single player |
| REST API | Scriptable | HTTP request | Automated pipelines |
| USB drive | Single player | Physical access | Air-gapped, no network |
Key Parameters
| Parameter | Value | Why It Matters |
|---|---|---|
| Downtime per player | 2–5 minutes | Minimal visible disruption |
| Rollback | Automatic on failure | Safe recovery from bad updates |
| Content preserved | Yes | No republishing needed |
| Release frequency | 2–4 times/year | Regular improvement cycle |
| Staged rollout | 5–10% → 24h → full fleet | Risk mitigation |
Common Mistakes
- Updating all players simultaneously. A firmware bug affecting all 500 players at once is catastrophic. Always stage: test → small group → full fleet. Catch issues before they affect the entire deployment.
- Never updating firmware. Running 3-year-old firmware misses security patches, performance improvements, and bug fixes. Schedule quarterly firmware reviews and apply updates within 30 days of release.
- Updating during business hours. A 2–5 minute reboot during peak hours causes visible downtime. Schedule firmware updates during off-hours using Arya's scheduled task feature.
- Not reading release notes. A firmware update that deprecates a feature your content uses will break screens. Always read release notes before upgrading — check for breaking changes.