Jellyfin 12 RC7 MigrateLinkedChildren deletes valid library items

[armitage6617]

I encountered a destructive migration issue upgrading Jellyfin 10.11.8 to 12.0 RC7 on Windows.

MIND YOU. I did force ffmpeg 9 encoding on my old setup.

Configuration:

Jellyfin 12.0 RC7 native Windows install
Database from Jellyfin 10.11.8
Media on an internal SATA HDD at E:\Video
Libraries:
E:\Video\MOVIES
E:\Video\TV SHOWS
E:\Video\DOCUMENTARIES
During startup, migration 20260113120000_MigrateLinkedChildren reported:

Checking 20548 items for missing files.
Found 3045 stale items to remove.
It then deleted valid movies and episodes whose files were present and accessible. Some deletions produced:

SQLite Error 19: 'FOREIGN KEY constraint failed'
UPDATE "LinkedChildren" SET "ChildId" = ...
The drive was online, connected by SATA—not USB—and the logged paths were verified to exist. A filesystem check and SMART check also passed.

The problematic RC7 migration is:

Jellyfin.Server/Migrations/Routines/
20260113120000_MigrateLinkedChildren.cs
MigrateLinkedChildren.Perform() migrates legacy relationship JSON, but then also calls CleanupStaleFileEntries(). In my database, that cleanup incorrectly classified 3,045 valid media entries as stale. The detection completed in milliseconds, despite checking over 20,000 entries.

Recovery
I:

Stopped Jellyfin.
Restored the pre-migration database backup.
Marked 20260113120000_MigrateLinkedChildren as applied so RC7 would not execute its destructive cleanup.
Ran a standalone migration that only:
Parsed LinkedChildren, LocalAlternateVersions, and LinkedAlternateVersions from BaseItems.Data.
Resolved child IDs by existing IDs and paths.
Inserted the resulting rows into LinkedChildren.
Did not delete any library items.
Migrated all 260 expected relationships.
Removed 515 orphaned BaseItemImageInfos rows left by the failed deletion attempts.
Ran PRAGMA foreign_key_check and PRAGMA integrity_check.
Final result:

LinkedChildren: 260
Foreign-key errors: 0
Integrity check: ok
Movies: 449
Episodes: 6095
Series: 58
Jellyfin then started normally with all libraries restored.

The safe migration helper I used is designed to be idempotent and validates database integrity before committing.

I believe stale-file cleanup should not be part of this relationship migration, or it should require substantially stronger safeguards before deleting records.

[crobibero]

We intentionally remove all items that aren't valid or are miscategorized. A full library scan is required upon upgrading to v12.
Though my response is pure speculation since there is no log attached to your post.

[armitage6617]

I understand that removing genuinely invalid or miscategorized items is intentional, and that v12 requires a full scan. My concern is that this migration does not establish that these items are invalid before deleting them.

The relevant logic in RC7’s 20260113120000_MigrateLinkedChildren is effectively:

var allLibraryPaths = accessiblePaths.Concat(inaccessiblePaths).ToList();
var canRemoveUnrootedItems = inaccessiblePaths.Count == 0;
if (!allLibraryPaths.Any(path => itemPath.StartsWith(path))
&& canRemoveUnrootedItems)
{
staleIds.Add(item.Id);
}
Jellyfin obtains those locations from .mblink files. In my installation, options.xml still contained all three configured paths, but the .mblink files were missing.

That produced:

accessiblePaths.Count = 0
inaccessiblePaths.Count = 0
allLibraryPaths.Count = 0
canRemoveUnrootedItems = true
Consequently, every external media path is “outside every library location” by definition. The migration classified 3,045 valid files as stale without proving that the files were missing:

Checking 20548 items for missing files.
Found 3045 stale items to remove.
The logs then show valid paths being removed, including existing movies and Stargate episodes under E:\Video. Those exact paths were verified to exist and the drive was healthy and accessible.

This is therefore different from intentionally removing invalid media. It is a fail-open condition caused by an empty location set. The code cannot distinguish:

all libraries intentionally deleted, from
incomplete/missing .mblink configuration, migration damage or an incomplete restore.
Requiring a full scan does not resolve the safety issue:

This deletion happens during startup migration, before the required post-upgrade scan.
Without the .mblink files, the subsequent scan also has no valid locations to scan.
Deleting and recreating items can lose relationships, metadata and other database state even when the media is later rediscovered.
After recreating the .mblink files with the exact paths, Jellyfin immediately rediscovered the libraries:

Movies: 495
Shows: 2771
Documentaries: 107
A safe condition would be something like:

var canRemoveUnrootedItems =
allLibraryPaths.Count > 0 &&
inaccessiblePaths.Count == 0;
Ideally it should also compare the discovered locations with configured PathInfos. If configured libraries exist but no locations are discovered, the migration should warn and skip destructive cleanup.

I will attach the complete startup log. (Soon as I figure it out I just joined this forum but I'm sure its fairly straightforward) The foreign-key failures occurred later while deleting referenced items; they appear to be secondary consequences rather than the initial cause.

[armitage6617]

I unfortunately due to privacy I can't post the log but hopefully the above helps, if not please feel free to remove my post/thread. Thanks for all ya'll do.