starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-05-04 18:09:12 +03:00
Code Issues 822 Packages Projects Releases 10 Wiki Activity

Changes to NFO files are not respected #6793

New Issue
Open
opened 2026-02-07 04:07:15 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-07 04:07:15 +03:00
Owner
Copy Link

Originally created by @ZhangTianrong on GitHub (Mar 4, 2025).

Description of the bug

Since a few releases ago (I am sorry I cannot identify the exact version since when the issue started. I cannot find relevant things mentioned in the changelog either.), Jellyfin ceased to pick up changes made to local NFO files during a scan and instead will overwrite them with its internal metadata. This change of behavior has also been brought up in the forum confirming that it is not a issue specific to me.

Reproduction steps

The problem occurs whenever a user want to modify the metadata through the NFO files. Here I just want to describe my common practice disturbed by this behavior change:

  1. Import new media into a library with or without existing NFO files.
  2. (optional) Let Jellyfin scrap for (missing) metadata.
  3. Identify that there are "inevitable" problems with the metadata.
  4. Modify the NFO files.
  5. Rescan for new and updated files only to find the changes to the NFO files reverted.

The problems could be the metadata provider is perfect at every aspect but it doesn't consider a season to be a part of a series while I wanted it to be (Jellyfin will insist that a file in a folder called Season 2 belongs to season 1 or 0 due to the metadata it fetched); the external ids are wrongly parsed because the names are so similar between seasons so I want to manually set the ids to make sure the fetched metadata are correct; I like the summary in the original language from a metadata provider but I would also like to extending them by translating them in the way I like; an actor changes the stage name but I want to keep them the same across different media, etc. They are problems that will always pop up now and then and it's not the user, the media distributor or the metadata provider's fault. I am willing to edit them manually and that is going to be mass editing. The interface for metadata management in the WebUI, however, is never prepared for mass editing and as as result I have been relying on writing scripts to modify the NFO files directly. I was able to do so by just rescanning after the editing, but now, I have to move the files elsewhere, scan so Jellyfin clears the metadata of them, modify NFOs, reimport to get the changes to the metadata adopted.

What is the current bug behavior?

Changes to NFO files are not respected and overwritten during scanning.

What is the expected correct behavior?

Jellyfin should always respect whatever content of the NFO files when it is used as the metadata store.

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

No response

Specify the build version

10.10.6

Environment

- OS: TrueNAS Scale Dragonfish 24.04.2.5
- Linux Kernel: 6.6.32
- Virtualization: Containerd
- FFmpeg Version: 7.0.2-Jellyfin
- Networking: Host
- Storage: local

The issue has nothing to do playback or specific clients.

Jellyfin logs

N/A

FFmpeg logs

Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @ZhangTianrong on GitHub (Mar 4, 2025). ### Description of the bug Since a few releases ago (I am sorry I cannot identify the exact version since when the issue started. I cannot find relevant things mentioned in the changelog either.), Jellyfin ceased to pick up changes made to local NFO files during a scan and instead will overwrite them with its internal metadata. This change of behavior has also been brought up in the [forum](https://forum.jellyfin.org/t-problem-picking-up-changes-in-nfo-files) confirming that it is not a issue specific to me. ### Reproduction steps The problem occurs whenever a user want to modify the metadata through the NFO files. Here I just want to describe my common practice disturbed by this behavior change: 1. Import new media into a library with or without existing NFO files. 2. (optional) Let Jellyfin scrap for (missing) metadata. 3. Identify that there are "inevitable" problems with the metadata. 4. Modify the NFO files. 5. Rescan for new and updated files only to find the changes to the NFO files reverted. The problems could be the metadata provider is perfect at every aspect but it doesn't consider a season to be a part of a series while I wanted it to be (Jellyfin will insist that a file in a folder called `Season 2` belongs to season 1 or 0 due to the metadata it fetched); the external ids are wrongly parsed because the names are so similar between seasons so I want to manually set the ids to make sure the fetched metadata are correct; I like the summary in the original language from a metadata provider but I would also like to extending them by translating them in the way I like; an actor changes the stage name but I want to keep them the same across different media, etc. They are problems that will always pop up now and then and it's not the user, the media distributor or the metadata provider's fault. I am willing to edit them manually and that is going to be mass editing. The interface for metadata management in the WebUI, however, is never prepared for mass editing and as as result I have been relying on writing scripts to modify the NFO files directly. I was able to do so by just rescanning after the editing, but now, I have to move the files elsewhere, scan so Jellyfin clears the metadata of them, modify NFOs, reimport to get the changes to the metadata adopted. ### What is the current _bug_ behavior? Changes to NFO files are not respected and overwritten during scanning. ### What is the expected _correct_ behavior? Jellyfin should always respect whatever content of the NFO files when it is used as the metadata store. ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version 10.10.6 ### Environment ```markdown - OS: TrueNAS Scale Dragonfish 24.04.2.5 - Linux Kernel: 6.6.32 - Virtualization: Containerd - FFmpeg Version: 7.0.2-Jellyfin - Networking: Host - Storage: local The issue has nothing to do playback or specific clients. ``` ### Jellyfin logs ```shell N/A ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_
OVERLORD added the bug label 2026-02-07 04:07:15 +03:00
OVERLORD commented 2026-02-07 04:07:19 +03:00
Author
Owner
Copy Link

@felix920506 commented on GitHub (Mar 4, 2025):

Please disable the save nfo files option.

@felix920506 commented on GitHub (Mar 4, 2025): Please disable the save nfo files option.
OVERLORD commented 2026-02-07 04:07:21 +03:00
Author
Owner
Copy Link

@ZhangTianrong commented on GitHub (Mar 4, 2025):

Please disable the save nfo files option.

Then how are metadata from metadata providers going be stored into the files in the first place? In the example procedure I showed above, I want to be able to edit the metadata “collaboratively” with Jellyfin, it obtains the most of the metadata and I patch them to fit my needs.

@ZhangTianrong commented on GitHub (Mar 4, 2025): > Please disable the save nfo files option. Then how are metadata from metadata providers going be stored into the files in the first place? In the example procedure I showed above, I want to be able to edit the metadata “collaboratively” with Jellyfin, it obtains the most of the metadata and I patch them to fit my needs.
OVERLORD commented 2026-02-07 04:07:24 +03:00
Author
Owner
Copy Link

@FrankJeager commented on GitHub (Mar 26, 2025):

Please disable the save nfo files option.

I have the same issue. Can you explain ?
I want my metadata be saved in NFO files inside media folders and i also want the changes made to the NFO files be respected. How to do that ?
(<lockdata>true</lockdata> in the NFO does nothing)

@FrankJeager commented on GitHub (Mar 26, 2025): > Please disable the save nfo files option. I have the same issue. Can you explain ? I want my metadata be saved in NFO files inside media folders and i also want the changes made to the NFO files be respected. How to do that ? (`<lockdata>true</lockdata>` in the NFO does nothing)
OVERLORD commented 2026-02-07 04:07:26 +03:00
Author
Owner
Copy Link

@elDub1234 commented on GitHub (Jul 20, 2025):

I have the same issue. I wanted to have some specials play in their correct place in between seasons. Rather than have to go through every episode manually to update airsbefore_season, I had Jellyfin save to nfo then wrote a script to insert this tag after the aired tag (which is what Jellyfin does if you do update this manually). When I then rescanned the library Jellyfin is not updated with this data (whether the save to nfo is checked or not). (In fact if save to nfo is checked it overwrites my inserted value with 0).

The Jellyfin documentation says "It's currently not possible to disable .nfo metadata. Local metadata will always be fetched and has priority over remote metadata providers like TMDb."

This seems to me that Jellyfin should always read the data from the nfo, even when the options for tmdb etc are set, but it is not reading it whether these options are set or not.

@elDub1234 commented on GitHub (Jul 20, 2025): I have the same issue. I wanted to have some specials play in their correct place in between seasons. Rather than have to go through every episode manually to update airsbefore_season, I had Jellyfin save to nfo then wrote a script to insert this tag after the aired tag (which is what Jellyfin does if you do update this manually). When I then rescanned the library Jellyfin is not updated with this data (whether the save to nfo is checked or not). (In fact if save to nfo is checked it overwrites my inserted value with 0). The Jellyfin documentation says "It's currently not possible to disable .nfo metadata. Local metadata will always be fetched and has priority over remote metadata providers like TMDb." This seems to me that Jellyfin should always read the data from the nfo, even when the options for tmdb etc are set, but it is not reading it whether these options are set or not.
OVERLORD commented 2026-02-07 04:07:28 +03:00
Author
Owner
Copy Link

@jellyfin-bot commented on GitHub (Nov 18, 2025):

This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.

If you have any questions you can use one of several ways to contact us.

@jellyfin-bot commented on GitHub (Nov 18, 2025): This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs. If you have any questions you can use one of several ways to [contact us](https://jellyfin.org/contact).
OVERLORD commented 2026-02-07 04:07:30 +03:00
Author
Owner
Copy Link

@TimF0 commented on GitHub (Nov 18, 2025):

So, if I'm reading the comments correctly, the desired operation is:

  1. JF scrapes the original data, creates a default .nfo file and updates the database
  2. Any changes made by the UI are reflected in both the .nfo file and the database
  3. Any manual changes made to the .nfo file are populated into the database on a scan
  4. If a value exists in a .nfo file, it shouldn't be overwritten on a rescan (apart from possibly a 'replace all metadata' scan)

1 & 2 are operating correctly, 3 & 4 aren't

I've always been a little confused on how the .nfo file and the database values can co-exist - I can see using one or the other but not both - except where, as mentioned in a comment above - you want an easy way to enter bulk updates...

@TimF0 commented on GitHub (Nov 18, 2025): So, if I'm reading the comments correctly, the desired operation is: 1. JF scrapes the original data, creates a default .nfo file and updates the database 2. Any changes made by the UI are reflected in both the .nfo file and the database 3. Any manual changes made to the .nfo file are populated into the database on a scan 4. If a value exists in a .nfo file, it shouldn't be overwritten on a rescan (apart from possibly a 'replace all metadata' scan) 1 & 2 are operating correctly, 3 & 4 aren't I've always been a little confused on how the .nfo file and the database values can co-exist - I can see using one or the other but not both - except where, as mentioned in a comment above - you want an easy way to enter bulk updates...
OVERLORD commented 2026-02-07 04:07:31 +03:00
Author
Owner
Copy Link

@ZhangTianrong commented on GitHub (Nov 20, 2025):

Yes, you read me correctly. I don't think you can choose to use NFO only (I am stuck with 10.10.6 so correct me if I am wrong). There is always going to be this internal metadata database except that you can choose whether or not to save a copy of NFO to disk. I would love to stick with NFOs but I cannot and that probably is not a very efficient approach to manage all the metadata either so maintaining a database is necessary. All I was asking is to allow users to overwrite the database with NFO once in a while and yes my primary reason for doing so it to perform bulk updates which I think is not that rare of a demand. Jellyfin is already capable of picking up metadata from NFO and propagate them to the database anyway except that it only happens when a new media is added to the library so I have to move the media away, scan, and then move the media back to trigger that behavior in a clumsy way.

@ZhangTianrong commented on GitHub (Nov 20, 2025): Yes, you read me correctly. I don't think you can choose to use NFO only (I am stuck with 10.10.6 so correct me if I am wrong). There is always going to be this internal metadata database except that you can choose whether or not to save a copy of NFO to disk. I would love to stick with NFOs but I cannot and that probably is not a very efficient approach to manage all the metadata either so maintaining a database is necessary. All I was asking is to allow users to overwrite the database with NFO once in a while and yes my primary reason for doing so it to perform bulk updates which I think is not that rare of a demand. Jellyfin is already capable of picking up metadata from NFO and propagate them to the database anyway except that it only happens when a new media is added to the library so I have to move the media away, scan, and then move the media back to trigger that behavior in a clumsy way.
OVERLORD commented 2026-02-07 04:07:32 +03:00
Author
Owner
Copy Link

@byangmath commented on GitHub (Jan 8, 2026):

This problem has really driven me crazy. The data I originally imported from the nfo file was correct, but later Jellyfin would change the nfo file back to the incorrect version. Even if I use TMM to update the nfo file, it will still be reset. The version of Jellyfin is 10.11.5.

@byangmath commented on GitHub (Jan 8, 2026): This problem has really driven me crazy. The data I originally imported from the nfo file was correct, but later Jellyfin would change the nfo file back to the incorrect version. Even if I use TMM to update the nfo file, it will still be reset. The version of Jellyfin is 10.11.5.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#6793
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?