Alternative linux player

Get Help Xibo Player for Linux
1

Since a lot of totems of mines cannot be upgraded to win11 I started making changes to improve arexibo playes for linux. In my fork GitHub - romoloman/arexibo: A Rust Linux Xibo player · GitHub I have ported most of the feature of existing window player and on my side seems to work rather well especially in X11 environment (I’m using under minimized ubuntu server with X11).
Test (and feedbacks) are welcome.

2

I’ve had a horrid time trying to get any of your apps installed on fresh OS installs

3

There is only one app and you need to compile it following the guide…

Building and running arexibo on Ubuntu 26

Quick reference for building arexibo from source and running it on a fresh Ubuntu 26.04 install. This covers development/testing use – for a full kiosk deployment (systemd service, X11 auto-start, screen rotation, touch calibration, etc.), see the separate deployment guide.

1. Install build dependencies

bash

sudo apt update
sudo apt install -y cmake g++ pkg-config libdbus-1-dev libzmq3-dev \
    qt6-webengine-dev

2. Install the Rust toolchain

arexibo requires Rust >= 1.75. Ubuntu’s own packaged cargo may be older than this – installing via rustup is the safer, recommended path:

bash

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
rustc --version

(If you’d rather use the distro package instead: sudo apt install -y cargo, then check cargo --version meets the minimum.)

3. Get the source and build

:warning: Important: github.com/birkenfeld/arexibo is the original, upstream repository – it does not include the bug fixes and features developed in this session (marquee/widget sizing fixes, XMR robustness, the pending-authorization feature, etc.). Use your own fork/copy with those changes instead if you have one, e.g.:

bash

git clone https://github.com/romoloman/arexibo.git

bash

cd arexibo

Either way, build with:

bash

cargo build --release

The binary is produced at target/release/arexibo. This step takes a few minutes the first time (compiling all dependencies from scratch).

To install it system-wide instead of running it from target/release/:

bash

cargo install --path . --root /usr

This places the binary at /usr/bin/arexibo. No other files are needed at runtime beyond the system libraries it links against.

4. First run: register with your CMS

Create a directory where arexibo will store its configuration and downloaded content:

bash

mkdir -p ~/arexibo-data

Run once, providing your CMS address and key:

bash

./target/release/arexibo --host https://your.cms.example/ \
    --key YOUR_CMS_KEY ~/arexibo-data

(--display-id is optional – if omitted, arexibo derives a stable id automatically from /etc/machine-id. Only pass it explicitly if you need to match an existing display record with a specific hardware key already assigned in the CMS.)

Log messages print to stdout. If the display needs manual approval in the CMS (Administration → Displays), arexibo shows a splash screen with this machine’s hostname and IP address while waiting, and retries automatically every 30 seconds – no need to restart it once you approve the display.

5. Subsequent runs

Once registered, the connection settings are cached in the data directory – you no longer need to pass --host/--key:

bash

./target/release/arexibo ~/arexibo-data

6. Requirements to actually see anything

arexibo needs a running X11 display to show its window – it won’t render anything over SSH alone without one. Options for testing:

  • A desktop session: if Ubuntu 26 is running with a desktop environment already, just run arexibo from a terminal inside that session.
  • A bare X server, no desktop environment (matches a real kiosk setup): xinit ./target/release/arexibo ~/arexibo-data -- :0 vt1 -s 0 -dpms (see the deployment guide’s “Standalone setup with X server” section for the full systemd-based version of this).
  • Remote debugging without a physical screen: QTWEBENGINE_REMOTE_DEBUGGING=9222 as an environment variable lets you inspect the rendered page from another machine’s Chrome/Edge at http://<host>:9222 (via an SSH tunnel if not on the same network) – useful for confirming content renders correctly without needing eyes on the actual totem screen.

Useful flags for development

  • --debug: verbose logging (SOAP calls, internal state transitions).
  • --web-debug: logs every JS console message and page error from the rendered content – useful when troubleshooting a specific widget that isn’t displaying correctly.
  • --allow-offline: tolerates the CMS being unreachable at startup, falling back to cached settings/content if available, instead of failing outright.
  • --clear: wipes the local file cache (downloaded media/widget pages), forcing a full re-download on next start. Does not affect cached CMS connection settings.
  • --no-verify: skips TLS certificate verification – only for testing against a CMS with a self-signed certificate, never for production.

Run arexibo --help for the full list.

4

Looks like I’ve conflated your arexibo instance with that from xiboplayer.org

I will give yours a go

5

There are also some useful environment variables

Normal use:

  • AREXIBO_FONT_SCALE: a numeric multiplier (e.g. 0.91) applied globally to font sizes, to correct for rendering differences compared to a reference client on a different platform. Leave unset for the default (no correction).
  • QTWEBENGINE_CHROMIUM_FLAGS: standard Qt/Chromium mechanism for passing extra Chromium command-line flags (e.g. GPU-related tuning for a specific graphics driver). arexibo appends its own required flag (--disable-pinch, needed to disable pinch-to-zoom on multitouch panels) to whatever you set here, rather than overwriting it – both apply together.
  • QTWEBENGINE_REMOTE_DEBUGGING: see section 6 above.

Diagnostic only – not for production use:

  • AREXIBO_FAKE_USERAGENT: overrides the user agent string reported to the CMS/widgets (e.g. windows to masquerade as a Windows client). Added specifically to investigate a rendering bug that turned out to be unrelated to the user agent at all – misrepresents the player to anything checking it, don’t leave this set normally.
  • AREXIBO_FAKE_CLIENTTYPE: overrides the clientType reported to the CMS during registration (currently only windows is implemented as an override value; anything else falls back to the real linux type with a warning). Added to test a hypothesis about CMS-side behavior differing by client type – same caveat as above, this misrepresents the player to the CMS’s own registration logic, which can affect other clientType-conditional CMS behavior beyond whatever you’re specifically testing.
6

BTW Arexibo is not a my istance, all the credits to the original author.
I only did some work to bring it very near (if not even more stable) to the original window client.

7

At the moment there are few things left back in my fork:
SyncGroup / VideoWall
Cycle Playback

All the other feature should work.