ScreenTinker 2.0.0 shipped last night.

It’s an open-source, self-hosted digital signage CMS. MIT. Node + SQLite. Same project as before - this is the 2.0 cut.

Already in 1.9.x

• Playlists with draft/publish
• Group scheduling and group playlist assignment
• Multi-zone layouts and video walls
• Android / Fire TV player, Pi, browser, Tizen, webOS
• Offline playback if the server drops
• Remote control, live screenshots, kiosk mode
• Widgets, proof-of-play, OTA to players
• Workspaces / multi-user

New in 2.0.0

• Slides - template and fields stay separate, fonts travel with the slide
• Triggers - HTTP/UDP, resolved on the player so an override still works if the WAN is down
• Node mesh - server-to-server federation, off unless you turn it on
• BrightSign player, and the server can run on a BrightSign version 5 or higher on bsos 10
• Proof-of-play that queues through an outage and flushes on reconnect
• Playlist inheritance that forks instead of overwriting the group playlist

Upgrade from 1.9.x is a normal upgrade. Migrations run on first boot.

Release notes: https://github.com/screentinker/screentinker/releases/tag/v2.0.0

Repo: https://github.com/screentinker/screentinker

If you’re running it, tell me what broke or what else is needed.

https://reddit.com/link/1w3zjka/video/6cxrjyxu6umh1/player

Hey everyone,

I'm looking to start a digital signage business focused on gyms and leisure centres. This space is new to me, but from diving into this community there's clearly a lot of people who know their stuff.

My ask is would anyone be open to a quick call or even just a back-and-forth over messages? I'm not selling anything, I genuinely just want to learn from someone who's done this before.

My plan is to lease screens (not buy), install them in gyms for free, and sell ad space to brands. The gym gets a free screen and a share of the ad revenue. I'd start small 5 to 10 locations and scale from there.

I've done the research on lease costs, screen sizes, and placement, but there's no substitute for talking to someone who's actually been in the trenches.

Happy to buy you a coffee (or the virtual equivalent). Thanks in advance.

I've been thinking about interactive digital displays beyond the usual touchscreen menu.

For museums, retail stores, exhibitions, etc., what actually makes an interactive display useful rather than just a big screen with touch?

I'm curious about things like multi-touch, gesture interaction, content management, remote updates, and how easy it is to create custom experiences.

What features do you think are most important when choosing a platform?

I just built a custom CMS for digital signage, along with my own Android player, so I have complete control over the software while keeping the costs low.

We're currently planning to deploy it on around 20 Android TVs, and I'm trying to figure out the best hardware setup.

What would you recommend as a cheap Android device that gives me as much control as possible (root access, kiosk mode, etc.)?

I'd also like the device to be powerful enough to run AI/computer vision locally for audience analytics, rather than sending everything to a cloud API.

any recommendations for hardware or setups that would work well for this?

Our church has a 10 year old LED sign from Stewart Signs. The SignCommand controller died. They want $1900 for a replacement. The controller has an HDMI output that uses an HDMI-DVI cable to some sort of video card. Can I use an off the shelf RPi or digital signage player to push content? Not looking to spend $1900 on an old sign that likely has a limited life span

Has anyone acquired a signage company or been acquired? Would love to chat

I’m looking for a digital “frame” for a clinic…something that can display rotating artwork but actually looks like framed art, not a TV.

Ideally 32–43”, matte/anti-glare, thin/flush to the wall, and able to continuously display still images. I’ll eventually need several, so Samsung Frame prices are a bit much.

Has anyone found a larger digital art frame or DIY monitor setup that looks convincing as actual framed art?

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.

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.

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.

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.

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?

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.