Shinage Player Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for digital signage / playback. This package is a concrete datapoint in the "do we build screen scheduling and media playback, or buy?" question. A PHP implementation of this domain exists — but it is archived, has 1 star and 0 dependents. That tells you the open-source PHP route has not produced a viable foundation, so if signage is on the roadmap, the realistic options are a commercial/self-hosted platform (Screenly, info-beamer, Xibo, Anthias) or a funded in-house build. It does not support "we'll just use the OSS package."
• Roadmap scoping for any "screen" surface. Kiosk, menu board, lobby display, warehouse status board, in-venue playback — all share the same problem set. Reading this repo gives a free requirements inventory: screens, playlists, scheduling, media sync, offline resilience, device state. Use it to pressure-test whether your v1 is a renderer, a scheduling API, an admin console, or device fleet management — most teams under-scope this as "just show a video."
• Stack-fit decision input. This is a Symfony bundle, not a Laravel package. For a Laravel team that is a decision, not an implementation detail: the PHP signage ecosystem skews Symfony, so any OSS leverage carries porting friction, and that cost belongs in the estimate before you commit to a stack or a vendor.
• Architecture boundary setting. The useful part of this repo is the browser-facing player (templates/assets/data contract), not the Symfony wiring. That supports a product-shaped decision: keep playback as an isolated surface (own release cadence, own component, feature-flagged) rather than embedding it inside the main application's release train. Signage failures are physical — a broken deploy means someone drives to a screen.
• Risk-register evidence. Archived + zero dependents is hard evidence for a "no unmaintained dependencies in an operationally critical path" policy. Playback is customer-visible and often on-site; it's the wrong place to inherit an abandoned library.
• Competitive/landscape framing. Knowing Shinage exists (German OSS signage suite) and that this slice of it is dormant sharpens positioning against both commercial SaaS and active self-hosted OSS.
• Estimate justification. A short read of what a "minimal player" actually entails — media formats, autoplay policy, caching, health reporting — makes a build estimate defensible instead of a guess.

When to Consider This Package

Consider it — as reference material only — when:

• You're running a discovery spike or writing a technical spec for a signage/playback feature and want a concrete PHP domain model to react to and borrow vocabulary from.
• You need to justify (or kill) a build estimate by showing what the minimum viable player surface really contains.
• You want to define the data contract for a player — what a "screen," "playlist," and "schedule" object must contain — and want a starting point rather than a blank page.
• Your team is Symfony-based and evaluating self-hosted signage backbones — and even then, read it, don't depend on it.

Look elsewhere — do not adopt — when:

• You're on Laravel. This is a Symfony bundle: no service provider, no publishable config/*.php, no facade, no auto-discovery. It registers services through Symfony's DI extension and kernel bundle system. Integration is a rewrite or an extraction, not an install.
• The requirement is production playback. An archived package with 1 star and 0 dependents has no maintainer, no security response, no PHP/Symfony compatibility guarantees, and no community to ask. Playback bugs are customer-visible and frequently require a site visit.
• You need a support path. No SLA, no vendor, no indemnity, no release notes, no issue triage.
• You need the operational surface. Device fleet management, remote configuration, proof-of-play analytics, content approval, and alerting on dead screens are almost certainly not in a "player bundle" — scope them separately regardless of what you pick.
• Your dependency policy requires maintained upstreams. Archived upstream + inherited transitive CVEs + PHP-version drift = a permanent internal maintenance tax with no rebase path.
• You need a maintained browser player. video.js / hls.js plus your own Laravel admin layer is a smaller, better-supported commitment than porting an abandoned one.

Recommended move: fund a 1–2 day spike to read the repo and produce a domain/requirements note plus a fork snapshot. Keep it out of composer.json. Then evaluate maintained OSS or commercial SaaS against that note.

How to Pitch It (Stakeholders)

Executives: Open-source PHP does not currently offer a viable, maintained foundation for digital signage playback. The one package we found in this space is archived, with effectively no users and no maintainer — that's a market signal, not a shortcut. If signage is on the roadmap, the real choice is a commercial platform or a funded thin build, and either way the operational surface (device management, proof-of-play, remote diagnostics) is larger than the player itself. Recommendation: treat this package as free research input — a head start on requirements — not a dependency we inherit. Two days of effort, no commitment, no risk. It also gives us a credible build-vs-buy number to put in front of the roadmap review.

Engineering: mztx/shinage-player-bundle is a Symfony bundle from the Shinage signage project — archived, one star, zero dependents, no upstream. We will not add it to the dependency graph; an unmaintained package in the playback path is the worst place to inherit risk, because the failure mode is a dark screen on a customer site. What we will do: fork a tagged snapshot into an internal repo (verify the license before copying anything), extract only the portable layer — templates, CSS, JS, and the expected data shape — and reimplement it as a single Blade component behind a feature flag, with a documented prop contract and Eloquent-backed interfaces for playlist/schedule resolution. Delete the Symfony wiring; don't keep it "just in case." Success criterion for the spike is visual/functional parity against fixture data, not architectural purity. Decision gate at the end of week one: if the player logic turns out to be thin or we already have an equivalent, we stop and use a maintained JS player with our own Laravel admin layer. Either way we own the playback path from day one — assume build, budget a code owner, a CI headless-render check, per-screen heartbeat/error reporting, and a recurring line item for PHP-version and CVE review of whatever we vendor. If someone proposes the package as a Composer dependency, the answer is no, and the archived status is the reason.