Jump to content

[Feature Request] Add warning/validation for nested library paths to prevent accidental rebasing and metadata


Recommended Posts

Posted

Hi Luke and Emby Team,

I recently experienced a critical cascading issue due to an accidental path selection, and I would like to propose a safety guardrail to prevent other users from running into the same problem.

### What Happened:
1. I already have existing libraries configured with specific child paths, e.g.:
   - `/mnt/media/movies`
   - `/mnt/media/tvshows`
2. When creating a new library, I accidentally selected the **parent folder** `/mnt/media` instead of `/mnt/media/new_subfolder`.
3. Emby immediately executed a **Rebase**:
   `Rebasing 121614 /mnt/media/tvshows to be underneath 122603 /mnt/media`
4. Realizing the misclick seconds later, I went back and clicked "Delete" on the `/mnt/media` path.
5. **The Cascade Disaster**:
   Because the parent was deleted, Emby cascaded and deleted the database entries and metadata caches for all existing child libraries (`Deleting path /config/metadata/library/...`), then recreated them with **brand-new Folder IDs** (`122604`, `122605`...).
6. As a result, Emby treated all existing thousands of files as brand-new first-time imports, triggering an unexpected 7+ minute full library scan, TMDB scraping, and media info extraction across the entire server.

---

### Proposed Feature Requests / Solutions:

#### Option 1: Path Validation & Warning Dialog (Immediate UI Guardrail)
When a user adds a path in the library setup, please add a simple path-hierarchy check:
* Check if the selected path **contains (is a parent of)** or **is contained by (is a child of)** an existing configured library path.
* If a conflict is detected, display a warning modal before applying:
  > *"Warning: The path `/mnt/media` is a parent folder of existing library `/mnt/media/tvshows`. Adding this path will alter existing library structures. Are you sure you want to proceed?"*

#### Option 2: 'Staged Changes / Draft Mode' for Path Editing (Best Root-Cause Prevention)
Currently, adding or deleting a path immediately fires a live API call that instantly mutates the database.
* If Emby simply staged path changes in the UI and only committed them when the user explicitly clicks a final **'Save & Apply'** button (similar to OpenWrt or enterprise router configs), any accidental path misclicks corrected within seconds would never touch the live SQLite database at all.
* This would eliminate the entire cascade disaster at the root with minimal backend architectural disruption.

---

Even experienced users can make a simple misclick in a folder picker. Adding either a warning check or a staging step would protect users (especially cloud mount / large NAS users) from accidental destructive rescans.

Thank you for considering this usability improvement!

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...