Skip to content

[Feature] Family features: server-backed PIN, QR approval, managed accounts, time limits #541

Closed

Description

@benklop

What problem does this solve?

The same gaps as the Moonfin-Core proposal (Moonfin-Client/Moonfin-Core#1912). In Smart-TV specifically:

  • The sign-in PIN (pinCodeProtection, pinCodeHash) lives in local settings only and isn't
    in SYNCABLE_KEYS, so it differs per TV.
  • Nothing nudges an admin to set a PIN.
  • The Quick Connect login shows a code only.
  • Access schedules aren't handled: a denied login isn't distinguished from other 403s, and
    there is no time-limit experience.

Proposed solution

Parity with Moonfin-Core, in this order, each as its own PR:

  1. QR on Quick Connect. utils/qrCanvas.js already draws QR codes for other dialogs.
  2. Time's up. Handle schedule denials at login and enforce the window in the app,
    including during playback. No plugin needed. Re-evaluate on resume, since webOS can
    suspend the app.
  3. Server-backed PIN (needs the plugin proposal) reusing pinLockout.js, with the
    local PIN as fallback. An admin PIN prompt after sign-in only when no server-side
    PIN is available (plugin absent or unusable).
  4. Managed accounts (needs the plugin proposal): filter the picker to the users the signed-in
    admin manages, plus a "Set up Family Accounts" action in that admin's settings. The app
    already has the Quick Connect initiate and exchange calls and keeps several users'
    tokens, so this adds one /QuickConnect/Authorize request.

Everything must work without the plugin.

Platform

webOS, Tizen

Server

Jellyfin

Alternatives considered

Waiting for Core to land first and following its implementation. Fine by me if you prefer that order.

Additional context

Activity

  1. github-actions commented on Oct 18, 2026

    @github-actions

    Thanks for the report, @benklop.

    Before anyone can pick this up it needs a little more from you, so it has been labelled Missing Template.

    This issue skipped the issue form

    It was opened without one of the forms, so the fields that say which version, platform and setup this involves are all missing.

    The forms also decide how an issue gets labelled, and those labels are what tell this bot whether to ask you for a screenshot or a diagnostic log. Skipping the form means nobody was prompted for the one thing the report actually needs.

    Please open a fresh one from New issue and pick the form that fits, then this can be closed as a duplicate. If you would rather not start over, paste the form's answers into a comment below and they will be picked up.

    • Bug: Playback for video or audio, which needs a diagnostic log
    • Bug: UI for anything visual, which needs a screenshot or recording
    • Bug: Seerr for requests and discovery
    • Feature request for something new

    Each label comes off automatically once that piece is sorted.

  2. RadicalMuffinMan commented on Oct 22, 2026

    @RadicalMuffinMan
    Contributor

    Dont open issues for things you're going to make pull requests for, its redundant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions