1. Overview
Media server that streams a library of ordinary files the user already holds, without a mandatory account at a vendor.
Category: Media & Creative.
2. Version and scope assessed
Version assessed: Pinned evidence c7ce6a1b56ee7dcc1896250df0f2f9deaa828a81.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | Not assessed |
| II | Longevity | Not assessed |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | Not assessed |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ? Not Verified |
| E3 Independent interpretation and recovery | ? Not Verified |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ? Not Verified |
6. Evidence and verification
- E1: Jellyfin documents built-in and manual backups covering the database, metadata, subtitles, trickplay, configuration, and data directories. (source), confidence high
- E2: The documented restore process is version-sensitive and can require restoring the same version or downgrading; migration to another media server was not tested. (source), confidence high
- E3: The NFO saver writes favourite/rating/playcount/watched/last-played/resume fields for the one configured UserId, returning early when no valid user is selected. NFO can carry selected user state, but this is not an export of every user's records or a substitute for a complete database backup. (source), confidence medium
- E4: Jellyfin is self-hosted and stores its data and configuration in operator-controlled directories. (source), confidence high
- E5: Restore rejects a manifest from a newer server and requires an exactly matching backup-engine version in the inspected implementation. It then overwrites extracted files and, when database restoration is selected, purges target tables before loading records. These guards and destructive steps are concrete source findings, not a successful restore or universal rollback guarantee. (source), confidence medium
- sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for Jellyfin does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
- longevity: E3 is not established for Jellyfin's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
- locality: The server, data, and configuration can run on local infrastructure without a provider account. (source), confidence high
- transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
- E3: NFO export can carry selected state for one configured user, not every user's records. Complete version-compatible database/config/metadata/subtitle/archive reconstruction, media preservation and cross-host per-user comparison are not demonstrated. (source), confidence medium
- E5: Restore has explicit server/backup-engine version guards and destructive extraction/table-replacement steps. Those code paths do not establish effective role/target approval, delete-media scope, inspectable user-state changes and available recourse across the server workflow. (source), confidence medium
7. Migration and recovery
Native storage format: Media files in folders, with a local server database and optional NFO metadata.
Synchronization or runtime model: Self-hosted server.
Example export or inspection command (not verified against any particular version or data set): find /media -name "*.nfo" | head
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- Source/retained-input inspection only; no installation or application restore performed.
- Same-version/cross-host recovery, complete archive coverage, media-byte preservation, per-user comparison, delete-media scope and observed network behavior remain untested.
10. Assessment findings and remaining work
Evidence update: 23 October 2026
- Resolved: The NFO saver writes favourite/rating/playcount/watched/last-played/resume fields for the one configured UserId, returning early when no valid user is selected. NFO can carry selected user state, but this is not an export of every user’s records or a substitute for a complete database backup. Source.
- Resolved: Restore rejects a manifest from a newer server and requires an exactly matching backup-engine version in the inspected implementation. It then overwrites extracted files and, when database restoration is selected, purges target tables before loading records. These guards and destructive steps are concrete source findings, not a successful restore or universal rollback guarantee. Source.
- Open: Same-version/cross-host recovery, complete archive coverage, media-byte preservation, per-user comparison, delete-media scope and observed network behavior remain untested. E5 needs restore/target and delete-media/user authority, clear destructive-state boundaries and independent recovery evidence.
Assessment follow-up: These bounded findings are incorporated into the evidence above. Eligibility and principle ratings are deliberately unchanged; their reconciliation and any blank-status fixes are deferred to the next pass. Reproduction details and retained inputs are in evidence/third-pass/batch-11/.
Human-readable criteria: Can a creator archive source material and editable state, reopen the project after version changes, and export important work in interoperable formats?
Rating reconciliation: 24 October 2026
E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.
Remaining: Same-version/cross-host recovery, complete archive coverage, media-byte preservation, per-user comparison, delete-media scope and observed network behavior remain untested. E5 needs restore/target and delete-media/user authority, clear destructive-state boundaries and independent recovery evidence.
Next without installing locally: Inspect a synthetic complete server backup plus media/config manifests and expected per-user records, then obtain same-version cross-host restore and permission/delete-media observations with explicit rollback material.
The individual decision and provenance are retained in evidence/rating-reconciliation/batch-11/. Overall: Insufficient evidence.
Contribute verification evidence for Jellyfin
Have you tested clean-machine restoration, format migration, or failure rollback for Jellyfin? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Individually reconciled in rating batch 11 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. Previously resolved questions are retained, not counted again. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.