How to Prevent Duplicate Movie Entries After Changing Storage Paths

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Prevent Duplicate Movie Entries After Changing Storage Paths - Zima Store Online

Prevent duplicate movies by making the old and new paths mutually exclusive before the media server scans the migrated library.

A storage migration can expose the same movie through two bind mounts, two library roots, a temporary copy, or a stale database record that survives after the old path is removed. The safest workflow is to freeze automatic scans, back up the application database, map the exact old and new paths, move or copy media in a controlled window, remove the obsolete source from the library, and run one deliberate rescan only after the server can see a single canonical location.

Map Every Path That Can Reach the Same Movie

List the library roots, Docker bind mounts, symbolic links, merger filesystems, network mounts, and temporary migration folders. Resolve one movie to its real path from both the host and the container.

Duplicates often appear because the scanner receives the same file under a new path while the old database item remains valid. A Jellyfin migration report reproduced the problem when moving library folders created duplicates.

Choose one canonical container path, such as /media/movies, and keep it stable even if the host storage source changes. A stable container path reduces future database churn because the application does not need to learn a new location for every pool or drive migration.

Pause Automatic Scans Before Copying or Renaming Media

Disable real-time monitoring and scheduled library scans during the migration. Otherwise, the server may index partial copies, see both locations, or record the same title while folders are being renamed in stages.

Take a backup of the media-server configuration and database before changing paths. This protects watched status, artwork choices, collections, users, and provider identifiers that a clean-library rebuild may not reproduce exactly.

Copy or move one small test folder first, verify checksums or file sizes, and leave the old source untouched until the new location is readable by the service account. Do not let both paths remain active library roots during this verification window.

Remove the Old Library Path Before Scanning the New One

Once the new path is verified, remove the obsolete folder from the library configuration or remap the existing container path to the new host source. Confirm that the old path is no longer reachable through another library or symlink.

Removing a path does not always purge every associated record immediately. A Jellyfin issue reports that metadata linked to removed paths persisted, which is why path cleanup must be verified rather than assumed.

Run the application’s supported library cleanup or full scan only after the old source is unavailable. Avoid manually editing the database unless you have a tested backup and a version-specific recovery plan.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Preserve Media Identity While the Files Move

Keep movie folder names, filenames, year markers, edition labels, provider IDs, and local metadata files consistent. A title renamed during the same migration may be treated as a different item even when its video bytes are unchanged.

Store local metadata and artwork intentionally. If identifiers such as TMDB or IMDb IDs are embedded in names or NFO files, preserve them so the new path resolves to the same movie identity rather than a second ambiguous match.

The ZimaSpace NAS data migration workflow is the adjacent check for protecting source data and validating permissions before the old copy is removed.

Distinguish Two Paths From Two Versions or Editions

Open both duplicate entries and compare their file paths, media information, provider IDs, runtime, edition tags, and availability. Two entries may be the same file through two paths, two physical copies, or legitimate versions that were grouped incorrectly.

Stale records can remain accessible after a path disappears. A Jellyfin report calls these phantom entries, which should not be confused with a second real movie file.

If both entries point to live paths, remove the unintended path from library scope. If one path no longer exists, use the supported cleanup process and verify the record disappears. If the files are intentional editions, apply the media server’s supported naming and grouping rules instead of deleting one blindly.

Duplicate pattern	Likely cause	Correct action
Two entries, two live paths	Old and new roots both scanned	Keep one canonical path
Two entries, one dead path	Stale database record	Clean library after backup
Two files, same title	Migration copy still present	Verify and retire old copy
Two intentional editions	Naming or grouping mismatch	Use supported edition naming

This classification prevents a database cleanup from deleting a legitimate alternate cut or higher-quality version.

Run One Controlled Rescan and Verify State

Re-enable scanning only after the canonical path is mounted, the old path is gone, and the service user can read the new location. Start one full scan and watch for removal and addition events around the migrated movie.

Some libraries have failed to remove files after a storage move even after the old path was deleted from settings. A Jellyfin report documents removed files remaining in the library, so the final check must compare database entries with real paths.

Verify that each movie appears once, opens from the new path, retains watched status and collections, and survives a service restart. Keep the old storage offline but intact until this audit passes; then retire it according to the backup and migration plan.