Emby Emby Emby Learn
  • Emby Home
  • Video
  • Audio
  • Media Files
    • Subtitles and captions
    • Photos and images
    • Metadata and discovery
    • Libraries and media collections
    • Playback and streaming
    • Media hardware acceleration
    • Displays and AV connections
    • Live TV and recording
  1. Emby Learn
  2. Storage and server platforms
  3. Data protection
  4. File checksums
Search Results for

    Show / Hide Table of Contents

    File checksums and content verification

    A file checksum summarizes bytes for comparison with a reference, detecting a change without supplying the missing original content.

    A checksum is a value calculated from data. Comparing a file's current value with a recorded reference can reveal that the input bytes changed.

    This is useful after copying a media collection or checking a recovery copy. The checksum does not contain another complete film, so discovering a mismatch is different from being able to repair it.

    The exact input matters

    For a small, original UTF-8 example:

    Input bytes: 61 62 63
    Text: abc
    SHA-256:
    ba7816bf8f01cfea414140de5dae2223
    b00361a396177a9cb410ff61f20015ad
    

    The two displayed digest lines form one 64-hex-character value. Adding a newline changes the input and produces another value. A filename or modification timestamp is not automatically part of a content hash.

    A whole-file comparison must use the same algorithm and the same byte range on both sides. Comparing a downloaded checksum for one edition with another remuxed file is not a test of whether their films look equivalent.

    A reference gives the result meaning

    Reference What a comparison can support
    Recorded before the transfer Whether the destination matches the earlier byte content
    Trusted publisher's value Whether the received bytes match that published artifact
    Newly calculated on both copies Whether the two current inputs agree under the algorithm
    Newly calculated only on the suspect file A baseline for later comparisons, not proof of its earlier correctness

    A cryptographic hash makes accidental equal-digest results extraordinarily unlikely for ordinary integrity checking. It does not make collisions mathematically impossible. A digest copied from an untrusted source also does not authenticate that source's intended content.

    Detection needs a recovery source

    If the live file and backup disagree, the hash says that the observed inputs differ. It does not independently tell you which version is intended. Retained generations, trusted manifests and application context help make that decision.

    Reading every byte also consumes storage and network work. A checksum pass across a large library can compete with playback and scans. That operation provides stronger byte-content evidence than size and timestamp comparisons, at the cost of actually reading the content.

    An intact checksum does not test the decoder, subtitles or library identification. A perfectly copied but unsupported media format remains unsupported. Integrity checking answers the byte-preservation question.

    See Also

    • Parity protection and reconstruction
    • Media backups and recoverable generations
    • Backup restoration: recovering a usable server

    References

    • NIST FIPS 180-4: Secure Hash Standard
    On this Page
    2026 © EMBY LLC. Please see our terms of use and privacy policy.
    Back to Top