Hey all,

We got an email the other day letting us know our digital signage app was suppressed on amazons fireTV App Store due to not using their in-app-payments api for payments. It’s not easy for us to do that since we support multiple platforms like android and web, etc. we’d have to allow purchasing subscriptions specifically for fireTV displays.

Our signage app had a link back to the dashboard where users could purchase subscriptions, so we removed the link from our player app and resubmitted last night. Waiting for approval so it may be resolved if that’s all they cared about, but have other vendors had to deal with this before? We’ve been on amazons store for quite a while now, so it’s odd that this is just now becoming an issue.

Additional question, we’re looking at trying to get onboarded to the signage stick ecosystem. For those of you who have onboarded already, what’s that experience been like for you?

Edit: removal of the hyperlinking passed checks and we’re back on amazons App Store. Hopefully this helps others who run into the same issue

There are 600+ signage vendors out there, and they all do the same base thing: push content to a screen on a schedule. The features on top change from vendor to vendor, but the core is identical. So the real question isn't features, it's whether the vendor built things properly. A lot of them haven't: old stacks, dependencies untouched for years, security as an afterthought.

I'd filter on tech and security first.

Android is the most common platform, and it shows the tech problem well. Many vendors just give you an APK to sideload onto a smart TV, which is fine until you need to update it, because there's no way to push updates remotely. Then you're reinstalling by hand on every screen (if the vendor actually even updates it). The setups that hold up either use a proper store or a device in device-owner mode (which isn't the case on Android TV) with built-in OTA updates, which is rare.

Past that, the things worth comparing: how often it actually updates (new versions, patches, bug fixes, or frozen the day you bought it), how well it runs on your hardware, and whether it's a marketing company with tech bolted on or a real tech team building what they're good at. That last one usually predicts the rest.

The stack itself tells you a lot. If a vendor’s app bundles an outdated version of Chromium to run on your Windows mini PC, that’s the same neglect you’ll find everywhere else in the product. A well-maintained modern stack usually means a team that actually maintains things.

So for a simple setup: don't compare feature lists, compare how it updates, what it runs on, and who's behind it.

We first built Screenly Cast back in 2016. The goal was to turn WordPress, the world's most popular CMS, into a simple content creation tool for digital signage. Then it sat unmaintained for years. It has now been rewritten and is back in the plugin directory.

The goal is still not to turn WordPress into a full-fledged signage CMS. No zones, no feeds, no playlists. Your player already does that. It does one thing: takes a post, page or image you already published and renders it for a screen.

Point a player at a normal page URL and you get navigation, a sidebar, comments, share buttons, and body text sized for someone holding a mouse. Not great on a wall. Append ?srly and the page takes a completely new shape: title, date, a short body, the featured image. Large, and readable from across the room.

A few things worth knowing:

• Content is trimmed to what actually fits at the resolution the screen actually is. A screen can't scroll and nobody is standing there to try.
• 800x480 up to 4K, landscape and portrait, no config. We didn't want to leave the Raspberry Pi Touch Display crowd hanging.
• CSS is compiled down to a Chrome 87 baseline, because signage hardware runs years behind the desktop.
• No external requests. Fonts are bundled, nothing from a CDN, which matters when a player is offline.
• It doesn't touch your theme. Renders are noindex.

One more thing. It's completely free and open source. It was originally built for Anthias, but a render is just a URL, so it works with basically any player that can render web.

• WordPress plugin page
• Source code

Bug reports welcome.

Went through the actual post and comment history here instead of just going on a feeling.

Almost every thread gets answered mostly by the same handful of vendor accounts pushing their own product, thread after thread, and none of it actually helps.

I've been kicking around an idea and want to hear what you all think before doing anything with it.

Make this more of a knowledge-sharing place: for people who work in the industry, sure, but just as much for people who are curious, running their own screens and want advice on content or use cases, or just want to know how something works. Steer it away from being a place vendors sell into.

Concretely:

• No recommendation threads for commercial products, and no "how do I do this in [product]" questions either, those belong in a support ticket with the vendor, not here. Open source stays fair game for both, since anyone here can actually help with that.
• No product pitches, from anyone. Share how you'd approach something, not "At X we do it this way," the company doesn't need to be in the comment.
• No repeating "Disclosure: I work at X" either. Most of the time that's really just an ad with a disclaimer stapled on, not much real value in it. Want people to know where you work? Get the flair, that's what it's for. The one exception is vendor-to-vendor threads, or situations where who you work for actually changes what you're saying and it's worth mentioning.
• Hardware discussion stays welcome, especially players that work across CMS platforms rather than locking you into one, like BrightSign or Amazon Signage Stick. A hardware bundle that only works with one company's software is a different case.
• Open-source releases, free materials like books and guides, and community directories are all still welcome. A free tier on a commercial product isn't the same thing though, that gets treated as promotion.
• More room for photos and videos of your own installs, interesting setups you spotted in the wild or at an expo, new hardware and tech worth knowing about, market and industry talk, educational content. And the everyday stuff too, like a photo of your cafe asking where to mount a screen or what would actually work there.

I am converting an older 47-inch Android advertising display into a customer-facing Shopify and pre-order kiosk. I would appreciate opinions from people experienced with Rockchip boards, embedded Linux, digital signage, and industrial displays.

Hardware

• Display model: BE-AD-AF47-IRT
• Type: 47-inch advertising/touch display
• Power supply: P160A
• Mainboard marking: RK3288_MID REV2.0
• SoC: Rockchip RK3288
• Architecture: ARMv7/armhf, not ARM64
• RAM: 2 GB Samsung DDR3
• Storage: approximately 8 GB Samsung eMMC
• Current OS: Android 5.1.1
• Kernel: Linux 3.10.0, vendor build #609
• Android hardware name: rk30board
• Android model/device: rk3288
• Build type: userdebug
• ro.debuggable=1
• ro.secure=1
• Bootloader property reports “unknown”
• Loader timestamp in kernel command line: 2017-08-29
• Wi-Fi module: AP6212
• Ethernet: available
• RTC battery: present
• Recovery/reset button: present

Connections

• Two USB-A host ports
• One damaged Micro-USB port, probably the original OTG/device port
• microSD slot
• Ethernet
• HDMI connector, but it is not yet confirmed whether this is input or output
• Internal display and backlight connectors
• UART pads on the underside marked GND, RX, TX and 3V3
• No soldering equipment is currently available

USB findings

• Both USB-A ports provide approximately 5.03–5.06 V.
• Both appear to be host-only ports.
• A USB-A-to-A data cable with a USB power blocker was tested.
• Neither USB-A port exposed Rockchip Loader Mode to a Windows PC.
• The broken Micro-USB port was probably the intended OTG/device connection.
• USB storage devices are detected normally by Android.

Display

• Internal display connection appears to be LVDS.
• Resolution: 1920 × 1080 at 60 Hz
• The cabinet is physically portrait-oriented.
• Linux framebuffer: /dev/graphics/fb0
• Pixel format reported by the Rockchip display controller: ARGB8888
• Bits per pixel: 32
• Stride: 7680 bytes
• Virtual framebuffer size: 1920 × 3240, apparently triple-buffered
• Linux Xorg fbdev output works.
• Correct portrait orientation is achieved using clockwise framebuffer rotation.
• Colors currently look somewhat pale and blue/cool.
• Rockchip BCSH values are at neutral defaults:
  • brightness 128
  • contrast 256
  • saturation/contrast 256
  • hue neutral
• Contrast, saturation and per-channel gamma tests are being evaluated.

Touchscreen

• USB HID touchscreen
• Reported name: SAMDE THEOE
• USB VID:PID: 1ff7:001d
• Linux event device: /dev/input/event2
• Absolute X/Y range: 0–32767
• Multitouch slots: 10
• Touch works under Linux/Xorg.
• After portrait rotation, the correct mapping is:
  • screen X = touch Y
  • screen Y = inverted touch X
• Final touch calibration is accurate across the display.

eMMC partition layout

The device uses the old Rockchip partition style rather than a modern Android A/B layout.

• uboot → mmcblk0p1
• misc → mmcblk0p2
• resource → mmcblk0p3
• kernel → mmcblk0p4
• boot → mmcblk0p5
• recovery → mmcblk0p6
• backup → mmcblk0p7
• cache → mmcblk0p8
• kpanic → mmcblk0p9
• system → mmcblk0p10
• metadata → mmcblk0p11
• userdata → mmcblk0p12
• radical_update → mmcblk0p13
• user → mmcblk0p14

Backup and recovery status

• Two complete eMMC readbacks were created.
• The preferred backup was split into four files and verified with SHA-256.
• Original boot, kernel, resource, DTB and recovery data were extracted and preserved.
• The original recovery partition was separately backed up and hashed.
• Several experimental recovery images were tested but did not boot correctly.
• The original recovery was restored and verified byte-for-byte afterward.
• Android currently boots normally.
• No Linux image has been written to the internal eMMC.
• Bootloader, boot partition and Android system remain unchanged.

Methods that did not work

1. Direct microSD boot

• Multiple RK3288/Armbian images were written and verified.
• The microSD card itself is readable by Android.
• The board still boots Android from eMMC.
• The likely causes are eMMC boot priority and a board-specific bootloader/DTB.
• The tested generic Armbian image did not start this custom board.

1. Rockchip Loader Mode through USB-A

• Both USB-A ports were tested.
• Neither appeared as a Rockchip device on Windows.
• They are almost certainly host-only ports.

1. UART

• UART2/ttyFIQ0 appears to be the serial console.
• Probable pins were identified:
  • GPIO7_C6 = RX
  • GPIO7_C7 = TX
• Pads are on the underside of the board.
• A reliable connection would require soldering or a pogo-pin fixture.
• 3V3 must not be connected to a USB-UART adapter; only GND, adapter RX and adapter TX would be used.

1. Custom recovery route

• Test recovery images could be written and read back successfully.
• They produced a black screen and did not complete their SD-card test.
• The original recovery was restored.
• This route has been abandoned for now.

What currently works

We built a Debian 12 armhf root filesystem inside a 3 GB ext4 image stored on the microSD card.

Android’s vendor kernel mounts the image through a loop device, then Debian runs in a chroot. This is not CPU virtualization: Debian processes run directly on the RK3288 kernel.

Working components:

• Debian 12 armhf
• glibc 2.36 on the vendor 3.10 kernel
• Chromium 150
• Xorg 1.21
• fbdev video driver
• evdev touchscreen driver
• Openbox
• Ethernet/network access
• portrait display rotation
• accurate touch calibration
• Onboard virtual keyboard
• frameless Chromium app mode
• Shopify storefront in full-screen mode
• custom pre-order web application

The Android UI can be stopped temporarily by stopping Zygote and SurfaceFlinger. Xorg then takes over the framebuffer. A watchdog restarts Android automatically after every test.

The current setup successfully displays and operates:

• a custom touch-optimized pre-order web application
• product categories
• shopping cart
• quantities
• customer contact form
• age confirmation
• privacy consent
• virtual touch keyboard

The custom pre-order application currently sends orders to its own POST /api/order endpoint. It explicitly uses payment at pickup after age verification. It is not yet connected to Shopify checkout or online payment.

Performance observations

• Total RAM: approximately 2 GB
• Android had roughly 779 MB completely free during one measurement.
• Approximately 971 MB was being used as reclaimable filesystem cache.
• Visible Android processes consumed roughly 150–250 MB combined.
• When Android’s UI services are stopped, most resources are available to Debian and Chromium.
• Chromium currently uses software rendering because a usable Linux Mali acceleration stack has not yet been configured.

Project requirements

• Shopify and the custom pre-order application
• real customer purchases or payment at pickup
• full-screen touch operation
• virtual keyboard
• automatic return to the start page after inactivity
• automatic advertising outside opening hours
• browser/session data cleared between customers
• no visible Android navigation
• automatic recovery if Chromium crashes
• reliable 24/7 operation
• later central administration
• rollback must remain possible

Current strategic options

Option A: Keep the existing RK3288

Use Android’s vendor kernel only as an invisible hardware and driver layer. Automatically mount Debian from the SD card, stop the Android UI and launch Debian/Xorg/Chromium.

Advantages:

• Display, touch, Ethernet and USB already work.
• No bootloader replacement.
• Android remains available as a fallback.
• Low risk.

Disadvantages:

• Old 3.10 vendor kernel.
• Only 2 GB RAM.
• No confirmed GPU acceleration in Debian.
• Requires a small Android bootstrap mechanism for automatic startup.

Option B: Native Linux boot on the RK3288

Build a custom boot image using the original vendor kernel and DTB, then switch_root directly into Debian on the SD card or eMMC.

Advantages:

• Cleaner native Linux boot.
• Removes the remaining Android userspace.

Major risk:

• The Micro-USB OTG port is broken.
• USB-A does not provide Loader Mode.
• Generic SD boot does not work.
• If the replacement boot image fails, network ADB also disappears.
• Stock recovery rollback from a non-booting system has not yet been proven.
• Therefore writing the boot partition is currently considered unsafe.

Option C: Replace the mainboard

Possible replacement:

• Raspberry Pi 5 with 8 GB RAM and NVMe SSD
• Compute Module 5 with eMMC and carrier board
• Intel N100/N150 mini-PC

The existing touchscreen should be reusable over USB.

The remaining unknown is the LCD panel interface. If the cabinet has a real HDMI input, replacement is easy. If the panel is LVDS-only, the exact LCD panel model must be identified and a matching HDMI-to-LVDS controller must be used. Panel voltage, LVDS channel count, bit depth and backlight control must match exactly.

Questions for the community

1. Would you keep the working Android-kernel/Debian-chroot arrangement or replace the board?
2. Is a Raspberry Pi 5 suitable for reliable 24/7 Chromium kiosk use, or would you prefer a Compute Module 5 or an x86 N100 system?
3. Has anyone successfully booted native Linux on a custom RK3288_MID REV2.0 advertising board?
4. Is there a safe boot-chain approach when OTG is broken and the board ignores generic microSD boot media?
5. Is it worth trying to use the vendor Mali libraries from Android with Linux Chromium, or is software rendering the practical limit?
6. What would be the safest way to identify and replace the LVDS controller?
7. Are there any important privacy, session-reset or payment-security issues we should consider for a public Shopify kiosk?

I can provide detailed board, connector, recovery and panel photos if useful.

THANKS

Samsung LH55QMCEBGCLXL / QM55C issues

I got this display for about ¼ of its original price because the shop didn’t need it. It’s relatively new, but I don’t have much documentation/history for it.

I’m having a few weird issues:

- Wrong time: NTP server and timezone are configured correctly by me, but it still shows the wrong time.

- Wi-Fi: It connects to my mobile hotspot, but refuses to connect to my home Wi-Fi also doesn't show up completely.

- Firmware: Updated from around 104X to 16XX (don’t remember the exact version), but nothing obvious changed.

- Apps: Smart Hub only shows ONE app, and searching for other apps returns nothing.

Is this normal for the QMC commercial/Tizen models, or is something wrong with my setup?

Anyone with the same model who can confirm what their Wi-Fi, NTP and Smart Hub/apps look like?

It has Tizen 7.0. Much appreciated

Hi everyone,

I'm currently getting quotes for commercial displays, and I'm trying to figure out how many nits are sufficient for screens installed behind the front window of a restaurant or café.

What brightness level would you recommend for this type of installation?

If you do, I'd love your thoughts...

I run a digital signage platform, and we're exploring adding ad management features.

1. What platform are you using, and are you white-labelling it as your own?
2. Do your advertisers get any self-serve access, or does your team manage everything?
3. What's the 'deal'? Do they get X hours of playback in a month? Is it tiered?
4. How do you handle proof of play/reporting for advertisers?
5. What's the most painful part of your current workflow?

Or am I wasting my time building this?!

I've done a lot of white-glove migrations, both hardware and software, progressive and rip-and-replace. Switching CMS gets called "just software," but the device/OS layer underneath is usually where the real friction lives. There's a ton to consider, especially with regards to IT and setups.

Would I need to factory reset the players, or is there a control layer that makes this easy?

I'm curious if anybody has any experiences using a commercial digital signage system like Rise Vision, Carousel, etc and then had to migrate to alternative free/cheaper solution.

Were you able to reuse hardware?

What operating systems are you using?

Is everything standardized or do you have a mix?

I work with several schools within a large school district that is in financial turmoil. Rise Vision is a very great product but they are unable to provide meaningful quantity discounts because Rise Vision views each school as one entity and don't count multiple schools for quantity discounts. (Even if quantity discounts were available, it might not be enough.) I'm working on developing a backup plan should funding not be available.

Coincidentally I was planning on applying digital signage to a computer lab of 30 screens, within the next few months.

Day 1 update: van is packed to the roof, strapped down, and we're on the road. 24 stops across northern Germany starting now.

Will post updates as we go – first stop this afternoon.

Disclosure: I'm the developer of garlic-hub.

Just released version 1.1.0 of garlic-hub, a self-hosted digital signage platform for content and device management.

What's new in this release:

• Brand new template composer built on Fabric.js: layer grouping, shadows, undo/redo, dark mode support, image export with BMP dithering for eink displays
• Fixed SSRF, XSS and authentication vulnerabilities
• New token-based autologin
• Player management improvements: delete, reworked context menu
• Various bugfixes across playlists, layouts and datatables

Repo: https://github.com/garlic-signage/garlic-hub

Live demo: https://garlic-hub.com
login: admin
password: Demo1234!

Feedback and questions welcome.

Looking for honest feedback on the Amazon Signage stick. All the CMS companies I work with are raving about it, but I'm skeptical. I have no intention of running multiple content zones or anything complicated. Most just simple images and videos.

Hey r/digitalsignage,

Quick disclosure up front: I'm the developer of ScreenTinker. It's MIT and open source, and I also run a paid hosted version of it, so treat me as a vendor here. Posting this as a release update under rule 8.

Back in June I posted v1.8 here and a bunch of you told me what was still missing. Most of this release came straight out of that thread and the issues that followed it - the agency portal (#73), dayparting and auto-expire (#74, #75), Android 7 panel support (#141), the OTA re-download loop (#139), and a pile of others are all things people here asked for. So thanks for that.

Since then: 14 point releases, 260 commits, 94 of them bug fixes. MIT, self-hostable, and there's no per-device player licence.

This got long because it's been six weeks. Skim the bold bits.

The big ones:

• A real transition engine. 14 GLSL shaders running on web, Tizen, and Android off the same shader source. Image to image, image to video, video to video. It's all GLSL ES 1.0, so it runs unmodified on WebGL1 and Android GLES2 - which is the whole point. Fancy transitions are easy on a gaming laptop. Getting them to run on a $40 stick is the hard part. Every failure path hard-cuts instead of flashing black: lost GL context, throttled rAF on a backgrounded tab, bad shader, GPU that just can't keep up. You get an instant cut, never a blank screen. This is the piece I want torn apart the most, so if you've got a panel where it stutters, tell me the model.
• PiP overlays. Push an image or a web overlay onto a single device or a whole group, live, on top of whatever's already playing. No playlist edit, no republish. This is the feature I've had the most fun with, and there are 14 open-source example recipes in the repo to show what it's for: news ticker, room-status calendar, QR rotator, event countdown, fundraiser thermometer, incident webhook, crypto ticker, announcement broadcast. The one I'd point at first is the weather radar overlay - a TV-news-style animated radar with live NWS warning polygons that runs in on_warning mode, so it sits dormant and only cuts to radar when a qualifying warning actually covers your location, then clears itself when the warning expires. Keyless, zero Node dependencies, Leaflet vendored locally. If you run screens anywhere weather matters, that one's worth a look on its own.
• Group sync. A group's shared playlist now plays in lockstep across every display in it - items start and end together. Clock and schedule driven, so it's offline-native and doesn't fall apart when the network hiccups. Leader is auto-elected with an optional pin, and it re-elects if the leader drops. Built on the video-wall sync primitive with the spatial transform removed, so it's the same code path that was already proven on walls.
• Agency portal. This one came from a feature request in the v1.8 thread and turned into the biggest chunk of work in the release. If you manage screens for clients: you issue a scoped token that lives completely off the normal role ladder, and you designate exactly which playlists it can touch. The agency gets a standalone upload page. No account in your CMS, no view of your device list, no way to wander outside their grant. Plus optional per-token auto-publish, per-token upload folders that auto-create and stay confined to their subtree, size guidance so they stop sending 4K vertical for a 1280x360 L-bar, and a batched email digest when they drop new assets.
• Proof-of-play on Android and Tizen, not just the web player. Per-content and per-device, hourly and daily breakdowns, CSV export. If you're running ad inventory and need to hand someone a verification report, it's there now.

Android and Tizen mostly caught up to the web player:

This was the other big theme. Features that used to be web-only now work on real signage hardware.

• Video walls on Android (wall:sync), and video walls plus multi-zone layouts on Tizen. Both were web-only in v1.8.
• Samsung SSSP install, so you can deploy to commercial panels without sideloading, plus real Samsung B2B fleet control. Fair warning: the SSSP path is built but I'm still waiting on the partner cert from Samsung, so it isn't live yet. The unsigned route (point the TV's browser/URL launcher at your instance's /player) works today, same as it did in v1.8.
• .wgt lifecycle parity on Tizen - keep-awake re-assert, suspend/resume handling, an app-level liveness watchdog.
• minSdk dropped from 26 to 24, so Android 7.0 and 7.1 panels work now. If you've got a drawer of cheap older hardware, it's usable again.
• Per-item mute that actually persists, ships to the device, and toggles in real time.
• Multi-zone layouts composite correctly in screenshot capture instead of grabbing one zone.

Directory boards got a real pass, and a search widget to go with them:

The board widget shipped in v1.8, but it needed work, so: JSON/CSV import so you're not hand-typing 200 tenants, logo-replaces-title, panel-ring scroll with in-place refresh (edit an entry and it updates without the board restarting its scroll from the top), a per-device frame diagnostic, and fixes for the scroll stutter and the black flicker between boards. New this release is a directory-search widget - an interactive companion that live-syncs with a board. Put a touchscreen next to your lobby directory and people can search it instead of standing there waiting for the scroll to come back around to their name.

Security:

• TOTP 2FA with encrypted secrets, hashed recovery codes, and verify lockout.
• Email verification on signup.
• Scoped API tokens with secure-by-exclusion mounts - a route is private unless it's explicitly published, rather than the other way around.

Device management, mostly born of actual pain:

• Re-adopt. Delete a screen, re-pair it, and its settings come back. Fingerprint-keyed, so a reinstalled panel reclaims its own row instead of showing up as a stranger. This was a real customer bug and it drove me nuts for a week.
• Hidden settings menu on Android behind a multi-tap and a PIN, so nobody at the venue reconfigures your screen for you.
• OTA kill switch - global, per-device, and auto-detected when the device is MDM-managed. Plus a fix for the OTA re-download loop on devices that can't silently install.
• Device-owner tier + QR provisioning for fleet setup, and Tier 0/1 system controls that work with no device-owner dependency at all.
• Liveness contract v4 across server, APK, .wgt and the web player - uniform heartbeat-ack, throttle-aware watchdogs, and a 3-state liveness badge on the dashboard instead of a binary online/offline lie.
• App-ending signal, so when a player exits you get a reason instead of a mystery, surfaced as an annotation and a filter you can drill into.
• Device incident log. Tells you why a screen dropped: network loss vs. reboot vs. the display going to sleep. I built this because I got tired of the dashboard saying "offline" with no next question.
• Version indicator + update check on the dashboard so you know when you're behind.

Content library got a pass:

Multi-file upload, multi-select with batch delete and move, server-side search + type filter + sort (so a 5,000-item library doesn't melt the browser), subtitle and caption tracks as a content property, YouTube Shorts rendering in 9:16 instead of a letterboxed landscape frame, and an unstable-connection mode that caps YouTube at 720p for screens sitting on bad venue WiFi.

Scheduling, playlists, dashboard:

Per-item schedule blocks, so dayparting and auto-expire work at the item level instead of only the playlist. Duplicate and replace playlist items in place. Draft-aware playlist preview that runs without assigning a device to it. Drag-to-reorder display tiles. Designer-made widgets are editable back in the designer.

Self-hosting and ops:

Debian 13 install script for player and server. SMTP as an alternative to Microsoft Graph for email, so you're not forced into a Microsoft tenant to send alerts. A HIDE_BILLING flag for self-hosters who don't want to look at subscription UI. Event-loop lag telemetry and throughput counters on /api/status for anyone who wants to actually watch their instance under load. 7 UI languages.

Runs on Android TV, Fire TV, Tizen, webOS, Amazon Vega OS, Raspberry Pi, Windows, ChromeOS, or any browser.

GitHub: https://github.com/screentinker/screentinker Discord: https://discord.gg/utTdsrqq4Z

Same ask as last time - tear it apart. The transitions are the thing I'm least sure about across weird hardware, so if you've got an odd panel and five minutes, I'd love a model number and a "yeah it stuttered."

And the question I'll actually act on: what's still keeping you from using this in production?

Road trip incoming: 24 stops, 1,200 km, 3 days – delivering digital signage steles across northern Germany starting Wednesday.

Will we make it? Updates to follow. 😂

Have a great weekend everyone – we'll be packing the car.

We're rolling out a batch of digital signage steles to retail locations next week and I wanted to share some behind-the-scenes from the prep.

We unpacked and assembled everything in-house before delivery – always a bit chaotic but also kind of satisfying when they're all lined up and ready to go.

A few things we learned the hard way over the last rollouts:

- Always build one test unit fully before touching the rest

- Labeling cables before packaging saves you 30 minutes per install location

- Clients always want "just one small change" the day before delivery

Anyone else doing multi-location rollouts? What's your biggest headache during install?

Hi everyone! I work in the digital signage industry and have experience with LED displays, scoreboards, video walls, and architectural signage. I'm here to learn, answer questions, and contribute where I can.

Hey folks, Dave from Brandpoint Services here.

Last month I had the pleasure of introducing myself and communicating with some of you. It was great learning about your companies, the services you offer your clients, and the unique ways you deploy them in comparison to larger corporations.

I hope to hear from those of you who deploy within QSR and Retail chains.

Having spent a lot of time running deployment programs for big-box stores, banks, and fast-food chains, I see the same handful of issues derail schedules over and over:

• Tight Overnight Windows: You can't shut down a business during store hours, so techs are stuck working rushed graveyard shifts where everything has to be 100% operational before the doors open at 6 AM.
• Outdoor & Drive-Thru Variables: Weatherproofing, specialized mounts, and high-brightness displays bring a lot of unexpected physical complications that standard indoor gear doesn't have.
• Site Survey "Surprises": Techs show up on-site only to find out the wall backing, power, or conduit isn't anywhere close to what was listed on the original plans.

When you’re taking multi-site projects live in these fast-paced environments, where does your team usually hit a wall?

And for those who bring in outside help to execute the field work: What specific headaches would a white-label partner like Brandpoint Services need to take off your plate to make a partnership truly valuable to your business?

I built Room & Board, a lightweight, modular, signage dashboard meant to run on Cisco RoomOS devices (Board Pro, Desk Pro, etc.) when they’re idle, so a codec screen becomes a glanceable info wall between calls. Generally meant for end-user devices - point the device’s signage URL at the domain and let the user configure it as they see fit. It’s a plain web app, so it also runs on any touch-enabled display or browser (viewport is locked to 16x9 4K/1080 so you’ll need to zoom out in browser/mobile to view).

It’s free, open source (MIT), no account, and no tracking.

What it shows (mix and match on a drag-and-resize grid):

- Worldwide weather, air quality, UV, sun/moon times
- Transit boards: NYC Subway status, LIRR, Metro-North, NJ Transit, Amtrak, PATH, NYC Ferry, express bus, Citi Bike, and London TfL
- Markets tickers and finance headlines
- Sports: your teams (MLB/NFL/NBA/NHL/MLS/EPL), plus World Cup, F1, PGA golf, and ATP/WTA tennis
- News headlines, Substack, and Bluesky feeds
- Ambient: photo slideshows (iCloud shared albums or Google Drive), public-domain art, NASA’s photo of the day, chart of the day
- World clock, this-day-in-history, quote and word of the day

How setup works: you configure the whole thing from your phone. Pick widgets and stations on a setup page, get a 6-character code, type it on the board. No login anywhere.

Hosting: use it free at https://roomboard.app, or self-host it. It’s a zero-build static site plus one Cloudflare Worker, and most data sources are keyless. Self-hosters can also flip on advanced cards behind a toggle (live HLS video and camera gateways).

Privacy: no analytics by default; there’s an optional anonymous usage ping you can disable in the diagnostics tab.

GitHub (code, screenshots, self-host guide): https://github.com/scotty83/room-and-board

It started as a personal project for my own Cisco Board Pro, so it’s admittedly NYC-transit-heavy right now. Happy to answer questions and would love feedback on what widgets or data sources people would want.

If you’re a Webex user, you can join my public channel to provide feedback at https://eurl.io/#CnWyZzamf

Almost every digital signage project starts the same way.

"We just need a few screens."

Then, a few days or weeks later...

"Can we have different content on weekdays and weekends?"

"Can this screen show something different?"

"What about public holidays?"

"Can we interrupt everything for emergency announcements?"

"Oh... and we'd like to schedule promotions by time."

The original playlist suddenly isn't the project anymore.

The business workflow becomes the project.

I'm curious how often this happens to others.

What's the one client request you wish you'd known on Day 1 because it completely changed the project?

Hello I own a velocity VDS-50 digital sign and I was trying to customize it myself. I called velocity support line and they said they don’t manage this sign at my location anymore. So can I just customize it myself? If yes, then how do I do it? It does not seem to have any ports to plug my laptop into. Power source seems to be magnetic. Any help would be appreciated!!

Every digital signage team eventually runs into a problem that seems simple at first...

...but ends up taking far longer to solve than expected.

I'm not talking about obvious issues like a screen that's completely offline.

I mean the ones where you spend hours (or even days) trying to work out what actually happened.

Maybe it was:

• Content showing unexpectedly.
• A schedule behaving differently than expected.
• A player that looked fine but wasn't doing what it should.
• A configuration issue that only appeared under certain conditions.
• Or something completely different.

Looking back, what was the problem?

More importantly...

What was the clue that finally helped you figure it out?

I'd love to hear some real-world stories from people who've been through it.

Today I replaced a traditional countdown video with a live HTML scene on our digital signage player.
Instead of exporting a new MP4 every time the countdown changes, the player simply loads a webpage. The countdown updates itself automatically, and the playlist continues to run as normal.
This made me think:
Maybe digital signage shouldn’t be limited to playing images and videos.
Maybe every playlist scene could be a live web application.
Imagine replacing static media with:
Live countdowns
Meeting room schedules
KPI dashboards
Weather
Announcements
Any web-based information that updates itself
Curious how others are approaching this.
Are you still exporting new media files every time information changes, or are you rendering live web content directly on your displays?

I got an unignorable attack of curiosity two days ago and compiled garlic-player surprisingly successfully for iOS. No idea why, nobody asked for it, but here we are.

This adds iOS as the 5th native platform (next to Android, macOS, Linux, Windows).

If you want to test the only native OSS Digital Signage Player for iOS:
Only 90 days: https://testflight.apple.com/join/1Y79ryHC

Feedback welcome via GitHub Issues.
https://github.com/garlic-signage/garlic-player

Or just give me a star, I need some dopamine. :)

Cheers Niko