Silo v1.0

Named sets of titles: shared (everyone sees) or private (owner only), hand-picked or rule-filled. Shared/smart authoring is web-admin; private authoring on web and Android; every client browses.

• Browse a Collections section and open one to list its members on every client.
• Shared collections show for everyone; private ones only for their owner.
• Smart/rule collections auto-populate and stay current; an empty one renders an empty state.
• A collection spanning a restricted library shows only the allowed members.
• Shared and smart/rule collections are created and managed by an admin in web admin: members, rules, ordering, artwork.
• Any user creates and manages their own private collections on web and Android; private collections respect profile access, so a kids profile cannot add restricted content.
• Shared/smart authoring stays web-admin only; TV clients consume collections with no create/manage entry point in release builds.

A release schedule of upcoming episodes, movies, and seasons, a week at a time.

• Week view lists upcoming episodes + movie/season releases; season premieres are distinguished.
• Shows only libraries the active profile can access; dates correct across time zones.
• An empty range renders a defined empty state.

Server-assembled home rows, including trending, seasonal, editorial, and mood rows, are authored centrally in web admin.

• An admin builds and reorders home rows in a web-admin builder; no config-file editing is required. Scheduled publication is post-1.0.
• A change to the row set updates the home screen without an app update; every client renders the same available rows.
• Each user reorders their own profile’s section order manually; the personalized order persists per profile while the available rows stay centrally defined. The order is a profile-level edit, visible and settable by an admin in the device & override audit.
• On Apple and Android, "featured" content appears as a media row (these platforms have no hero concept).
• A profile never sees rows/tiles for content it can’t open; a row resolving to zero accessible items is omitted.

Tap an actor or director to browse their other in-library work.

• A person page lists their other in-library work, with photo and a missing-photo fallback, on every client.
• People are searchable; search returns matching cast/crew, not only titles.
• Person metadata is backfilled proactively: a person’s photo/bio is present without a user having to open the page first, and entries that are missing or stale beyond a threshold are refreshed within a bounded window.

Personalized "For You" suggestions with enough variety to avoid repeating the same titles, plus useful choices for a new profile. Produced server-side and shown everywhere.

• The server produces a personalized, varied set per profile, refreshed in the background, with sensible picks for a new profile.
• Clients render it where present; if the recommender has no output, clients fall back to a default row rather than an empty shelf.

Intro/recap/credits segments with a Skip button. The server detects markers locally or obtains them from enabled marker-provider plugins; every client consumes the resolved markers.

• The server detects intro/recap/credits locally or retrieves them from an enabled marker provider on the reference test set, within an accuracy target; no manual tagging required.
• Marker data is extensible through marker-provider plugins. TheIntroDB is one marker provider; additional providers use the same server-managed interface to supply or accept intro, recap, credits, and preview markers.
• Every client shows a Skip control at the right time with a countdown.
• Manual seek always works; a wrong or missed detection never blocks playback.

Admins and authorized users create, adjust, and remove intro/recap/credits markers in the web app, including markers supplied by a provider. Movie & Series libraries only.

• From the web app, an admin or an authorized user adds, edits the in/out points of, or deletes a marker on a Movie or Series item; the change takes effect on every client without a rescan.
• Marker-edit permission is grantable to an authorized (non-admin) user and enforced server-side.
• Manual edits win over and survive re-detection and rescans (lock-on-edit); audiobook and other library types expose no marker editor.

The server generates thumbnails at chapter and marker positions, and the web app displays them. Native clients support chapter navigation without preview images; native preview rendering is post-1.0.

• The server generates chapter/marker thumbnails (per-library setting) including on hardware-accelerated paths; absence degrades silently.
• Web shows the preview image at chapter/marker points; native clients ship chapter navigation without preview images.
• Full timeline scrubbing-trickplay is out of scope.

Per-profile subtitle behavior and appearance, auto-selected by audio language and customizable, with series-level overrides that sync across every client.

• Subtitle display settings (font, size, color, background, position, timing) are a profile-level preference, applied automatically and carried across devices for that profile.
• Subtitles auto-select based on the detected audio language; e.g. foreign or partially-foreign audio surfaces the matching/forced subtitle track without the user choosing each time.
• A manual subtitle override (track choice or on/off) applies to the entire series, not a single episode, and persists.
• Changes to subtitle preferences or overrides are reflected on every client; the preference is server-synced per profile.
• Appearance renders consistently across clients; selected captions stay legible and on time, per the section 4 accessibility bar.

Find and download human subtitles from providers on every first-party player, or upload your own from the web app.

• Upload is available to any user; the search button is hidden until a provider is configured.
• Subtitle actions live in the subtitles panel, not the overflow menu.
• Search and download are available during playback on web, iPhone, iPad, Apple TV, Android phone, Android tablet, and Android TV. Upload remains web-only.
• A downloaded or uploaded subtitle is attached to the item and immediately selectable for every profile, on every account, that can access it. Adding a subtitle never changes another profile’s current selection or subtitle preferences. A malformed upload is rejected with a clear message.

During playback, a user can translate an existing text subtitle or generate subtitles from an audio track when the server enables AI subtitles. The completed track is saved on the item and consumed like any other subtitle.

• Every first-party player exposes the AI subtitle action when the server reports translation or transcription available. A user can translate a compatible text subtitle, transcribe an audio track, or transcribe and translate it.
• The server enforces configured per-account transcription quotas for non-admin users. The player shows the remaining allowance and reports quota exhaustion without interrupting playback.
• A completed track is saved on the item, immediately selectable for every profile on every account that can access it, and labeled as AI-translated or AI-transcribed.
• Generation is rate- and cost-guarded and the provider path complies with the section 6 provider-compliance gate; a failed generation reports a clear reason and never blocks playback.

Download titles to watch offline on a phone or tablet, under server-enforced limits. iOS and Android only.

• On a mobile client: download a title, manage downloads, and play with no connection, under the server’s bandwidth/storage limits.
• An interrupted download resumes or fails cleanly; no corrupt half-file is presented as playable.
• The offline copy respects profile access and any server-enforced expiry. tvOS and Android TV are out of scope.

From the Silo mobile app on a phone or tablet, send a title to the Silo TV app on the same network and use the mobile device as a full remote. The TV app plays it directly from the server; the mobile device hands off and controls playback, and does not relay or cast the video. This works across platforms on the same LAN.

• Any signed-in first-party mobile app on iPhone, iPad, Android phone, or Android tablet can discover and control either Apple TV or Android TV on the same LAN. Selecting the TV or sending a title completes the secure profile handoff automatically in the normal flow; the user is not asked to pair or confirm the connection. Platform pairing does not matter.
• After handoff the mobile device acts as a full remote (play/pause, seek, audio/subtitle, quality, volume) and stays in sync; it never transcodes or relays the stream.
• Same-LAN only. If the TV app drops, the phone surfaces a disconnect and recovers rather than hanging.

GPU-accelerated transcoding (NVENC / QSV / VAAPI / VideoToolbox) with tone-mapping.

• On a host with a supported GPU, hardware encode/decode is auto-detected and used, with config to force or disable it; falls back to software cleanly.
• HDR → SDR tone-mapping produces correct color on the hardware path.

Transcoding spread across multiple worker nodes with per-node caps and live monitoring.

• An admin can register a node, place it in a co-location group, set job + bandwidth caps, and see live node sessions; a node going away fails over without orphaning a stream.
• Single-node is the zero-config default; multi-node is opt-in.

Multiple profiles per account, each with its own progress, optional PIN, and library limits.

• Switch profiles on every client; each has independent progress and preferences.
• Profile startup behavior is set per device. Phones, tablets, and web remember the last active profile by default; TV clients show the profile picker on launch by default. After a TV profile is selected for the first time, the TV offers to remember it for future launches. On any client, the user can choose to remember a profile or ask who is watching at launch.
• A remembered profile opens without asking for its PIN on every launch. Selecting a different PIN-protected profile, or using a device that does not remember the profile, requires that profile’s PIN.
• PIN gate enforced; kids mode hides restricted libraries and content.
• Library restrictions are enforced server-side; a restricted profile cannot reach content via deep link, search, person page, or stream URL.

Save for later, mark favorites, and rate titles per profile, synced across devices.

• Toggle watchlist/favorite/rating from a title page on every client; state is per-profile and syncs across devices.
• Dedicated lists are easily discoverable in nav and fully browsable.
• Toggling while offline queues and syncs on reconnect, or fails visibly; never a false "saved".

Users manage their own signed-in clients on the web, and server admins can invalidate a client session for any user. Mobile and TV apps do not surface session management in v1.0.

• A user lists active sessions with device/last-seen and revokes one; the revoked session loses access on its next request.
• A server admin can inspect a user’s active sessions, invalidate one client, or sign that user out everywhere without changing the user’s password or affecting other accounts.

Server admins create scoped API keys for server automation and integrations. Regular users and mobile/TV clients do not manage API keys in v1.0.

• Only a server admin can create, view metadata for, rotate, or revoke API keys. Each key has a defined scope and its secret is shown only when it is created.
• Regular users cannot create API keys.

Set up a TV without typing credentials by approving its device code in a browser or handing over signed-in servers from a phone or tablet on the same LAN.

• A TV client shows a device code; approving it in a browser signs the TV in within the code’s validity.
• When a signed-in Silo app opens on a phone or tablet, it discovers Silo TV apps awaiting setup on the same LAN and offers to sign them in. After code confirmation, it hands over its signed-in servers. An iPhone, iPad, Android phone, or Android tablet can set up either Apple TV or Android TV.
• Manual fallbacks, such as typing the server URL or signing in with credentials, are always present and offered.
• An expired or mismatched browser, mobile, or TV code fails closed and can be retried.

Create accounts, set up household or guest access groups, and invite people with the right library access and limits from the start.

• From web admin, an admin creates accounts, access groups, and invitations.
• An access group sets the inherited policy for its members: library access, playback-quality and stream/transcode limits, download and request permissions, and the permissions members may receive.
• A member account inherits its access group’s policy unless an admin sets a specific account-level override. All effective limits are enforced server-side, not only hidden in the UI.
• Admin accounts never belong to an access group. An invitation can assign a recipient to an access group so its policy applies when the account is created.
• User management is web-admin only; mobile and TV clients do not expose it.

An admin acts as a non-admin user to reproduce and diagnose what that user sees.

• From web admin, an admin starts an impersonation session for a non-admin user and sees the experience as that user.
• Impersonation cannot target another admin or escalate privileges; it ends cleanly and returns the admin to their own identity.

A self-contained request system: a user asks for a movie or show the server doesn’t have, an admin approves it, and when the content is later scanned in and identified it’s marked available and the requester is notified.

• From the web app, a user searches for and requests a movie or show the server doesn’t have; a request for content that already exists is prevented, and if the title is already requested the user can add themselves to be notified when it becomes available instead of requesting it again.
• A request moves through a status lifecycle (pending → approved/declined → available); an admin can approve or decline, and per-user request permissions/limits are enforced.
• A user can be set to auto-approve on a per-user basis; their requests skip the pending state and go straight to approved.
• When matching content is scanned in and identified, the server marks the request available; no external service is required.
• Everyone who requested or followed the title is notified when it becomes available.
• The request system is extensible through a request-router plugin interface; community-maintained extensions can be installed to automate how requests are sourced.
• Requests ship in every first-party client, gated by the server’s requests_enabled capability; a server with requests off shows no request entry point anywhere. Request administration (approve/decline, limits, auto-approve) stays web-admin only.

See every active stream and remotely stop/pause/resume or broadcast a message.

• Web admin lists active sessions (who, what, transcode vs direct, node); admin can stop/pause/resume one and send a message clients surface.
• A stopped session ends cleanly on the client. No mobile/TV admin surface.

Re-identify, fix fields, and choose artwork for mismatched items.

• Re-identify an item against providers, apply a match, edit core fields, and pick from available artwork.
• Changes persist and survive rescans (lock-on-edit where supported).

Auto-translate titles, overviews, and other metadata into a user or profile’s primary language. Translations can be generated while browsing and cached; admins can still prewarm translations from web admin.

• A user/profile primary language controls the preferred metadata language on every client; clients render localized fields where present and fall back to the source language otherwise.
• While browsing, the server can generate missing metadata translations on demand and cache them so v1.0 does not require pre-translating every item in the library.
• From web admin, translating an item or library can prewarm missing localized fields for a selected language.
• Machine-translated fields are marked as such and do not overwrite human- or provider-supplied translations.
• The provider path is rate- and cost-guarded and complies with the section 6 provider-compliance gate.

Bandwidth/quota limits, API rate limiting, and a filterable audit log.

• Admin sets global + per-user bandwidth/quota limits and they are enforced; rate limits throttle abuse.
• An audit log records user and permission actions and is filterable, with live streaming.

The server tracks devices and resolves settings per device and per profile. In web admin, an operator can inspect the effective setting for a device/profile combination, see where it came from, and correct an override when needed. The layout of that control surface is not prescribed.

• The server registers each device a profile uses (id, name, platform, last-seen) and records each login as a session with device + IP. Web admin provides a practical way to find a device and inspect its settings and overrides.
• Settings resolve by precedence: device override → profile/user value → default. The effective value reports its source (device / user / default).
• A user sets and clears overrides for their own device (e.g. preferred quality, audio language, auto-skip intro/recap/credits, HDR, playback speed, subtitle sync) for the active profile; overrides are profile-scoped, so switching profiles on the same device sees its own values.
• An admin can inspect and correct the relevant device-level override or profile-level setting for any user, including a profile’s home section order.
• Boundary: device tracking is automatic from client-reported headers and enforced server-side; v1.0 has no device blocking/approval and no trusted/blocked device state.

Install metadata and marker plugins from the first-party catalog, and request/source-adapter plugins from the community catalog once enabled; they auto-update.

• From web admin, install a plugin from the catalog; it loads and is usable.
• Catalog installs and updates are SHA-256 checksum-verified against the selected catalog; an incompatible or failed plugin degrades gracefully. Publisher-signature verification is post-1.0.
• The first-party catalog is enabled by default; the community catalog is off until an admin explicitly enables it.
• Every plugin displays its tier (first-party, community-vetted, or external), and community/external plugins show their disclaimer notice.
• A plugin installed outside the configured catalogs is marked Unverified and is not eligible for unattended auto-update.
• No plugin-management UI in mobile/TV clients.

Brand the server: name, logo, favicon, login background, and accent color.

• Server stores and serves name/logo/favicon/login-background/accent and applies them on its web surfaces.
• First-party clients do not adopt server branding.

A self-contained scan intake system: an external source tells Silo that files changed, Silo maps the signal to a library/path, and the server performs a targeted rescan without waiting for the schedule.

• Silo exposes an authenticated scan intake path that accepts a library/path change signal; when matching content is scanned in and identified, it appears in the library without waiting for the scheduled scan.
• The server owns signal intake, path mapping, debouncing, scan queueing, and result reconciliation; no external media-server refresh endpoint is required.
• Signals are debounced so bursts of changes do not hammer the scanner.
• The scan intake system is extensible through a source-adapter plugin interface; community-maintained extensions can be installed to connect automation tools, download clients, or other file-change sources.
• Web-admin configuration: admins configure sources, connections, path mappings, and inspect activity in web admin. Mobile and TV clients expose no autoscan configuration.

Alerts for opted-in events through the web inbox, Discord, email/digests, web push, webhooks, and native push to phones and tablets.

• Delivery: the server delivers opted-in events (e.g. requested content arrived) through every supported channel.
• User control: a user chooses which event types use push and registers or unregisters a device; tokens are revoked server-side on sign-out or session revoke.
• Web inbox: the web app includes a notification inbox with read state and preferences.
• Mobile push: an opted-in event (e.g. a request was fulfilled) wakes iOS and Android through APNs/FCM.
• Privacy: the push payload contains no media title, server URL, user name, or notification body. A first-party maintained relay receives only an opaque device/registration target and never learns the server identity, notification contents, or library contents.
• Resolution: after wake, the client connects directly to its own Silo server to fetch pending notification contents and deep-link context; tapping the notification opens the relevant item once fetched.
• Boundary: tvOS and Android TV push are out of scope, and no native mobile or TV notification inbox ships in v1.0.

Reconcile watched-status from Plex/Jellyfin webhooks.

• Plex/Jellyfin webhooks keep watched-status in agreement. Server-side only.

Bring watch history in when moving from another server. Users can import their own history, and an admin can assist with household-wide migration and repair.

• A signed-in user connects their own Plex, Jellyfin, or Emby account and imports watched status, play counts, last-watched, and resume positions into one of their own Silo profiles, matched by IMDb/TMDB/TVDB IDs.
• A user can see only their own import runs and results; an import cannot target another account or profile.
• For an admin-assisted household migration, an admin pulls the external user list, maps each person to an existing Silo profile, and can run or repair watch-history imports for those mappings. The mappings persist for later imports.
• Admin-assisted import does not create Silo accounts or profiles and does not copy library permissions from the source server.
• Emby imports can use Emby Connect to discover a server, then import from the selected source server; Plex and Jellyfin use their own source-server sign-in/token flows.
• Live progress shown; unmatched items reported; re-running doesn’t double-count; a partial import can be re-run safely.

Silo exposes a Jellyfin-compatible API so existing third-party clients can connect, browse, and play movies and series. Audiobookshelf compatibility remains beta and is deferred with Books.

• A representative third-party Jellyfin client can authenticate, browse, and play against Silo, covered by an explicit smoke-test matrix.
• The compatibility surface respects the same profile access and content rating as the native API.
• Documented boundary: which client features are in or out of the compatibility promise.