Content publishing is the process of transferring designed signage projects from your authoring tool to SpinetiX media players. SpinetiX supports two methods: direct push from Elementi (on-premises) and cloud-managed pull from Arya. Both use differential sync — only changed files transfer after the initial publish. Players use double-buffering to switch content without interrupting playback.
When to Use This Guide
- Just finished your first project in Elementi and need to get it onto a player
- Managing multiple players across different locations and need a fleet publishing strategy
- Migrating from USB-based updates to network-based automated publishing
- Choosing between Elementi and Arya for your production publishing workflow
How Content Publishing Works
Method 1: Direct Push from Elementi
Elementi publishes content directly to a player's IP address over HTTP. No cloud, no middleware, no server. Your PC talks to the player on the same network. Steps:
- Open your project in Elementi
- Go to Publish → Network Publish
- Enter the player IP address (or select from discovered players)
- Click Publish — content transfers and starts playing immediately
Best for: development, demos, small deployments, air-gapped networks. Requires your PC and the player to be on the same network segment.
Method 2: Pull from Network Share
Configure the player to fetch content from a shared network folder (SMB/NFS or HTTP server). The player checks the folder periodically and downloads new content automatically. This is the standard production workflow for on-premises deployments.
Best for: enterprise deployments with IT-managed content repositories, automated content pipelines.
Method 3: Arya Cloud Publishing
ARYA is SpinetiX's cloud CMS. Upload content through a browser, assign to player groups, and Arya pushes updates to all connected players automatically. Includes team collaboration, approval workflows, and campaign scheduling.
Best for: distributed teams, multi-site deployments, managed service providers.
Differential Sync
After the initial full publish, SpinetiX players only download files that have changed. A 20 MB project where you updated one image? Only that image transfers. This saves bandwidth and reduces update time from minutes to seconds on large deployments.
Key Parameters
| Parameter | Value | Why It Matters |
|---|---|---|
| Push Protocol | HTTP | Works on any network, no special firewall rules |
| Pull Protocols | HTTP, SMB, NFS, WebDAV | Flexible integration with existing infrastructure |
| Sync Type | Differential | Only changed files transfer — saves bandwidth |
| Content Switch | Double-buffered | No black screen during updates |
| Offline Behavior | Local storage fallback | Content keeps playing even if network drops |
| Multi-Player | Unlimited targets | One publish action, all players update |
Common Mistakes
- Publishing over Wi-Fi for large projects. Use wired Ethernet for initial full publishes (100+ MB). Wi-Fi works for differential updates but is unreliable for first-time bulk transfers.
- Not using differential sync. Re-publishing the entire project every time wastes bandwidth. Let the player handle file-level differentials automatically.
- Forgetting offline resilience. Always verify that content plays correctly when the player is disconnected. SpinetiX players cache everything locally — but only if the first publish completed fully.
- Using USB for production updates. USB is acceptable for initial setup. For ongoing content updates, always use network publishing. Walking to each screen with a USB stick doesn't scale past 3 screens.
- Publishing without testing preview. Always preview in Elementi before publishing to production players. The preview engine renders identically to the real player.