[Issue]: renaming a library will trigger a recreation of it and loose all it's settings/adjustments #4395

Closed
opened 2026-02-07 00:48:41 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @da-anda on GitHub (Dec 1, 2022).

Please describe your bug

One might think that changing the name of a library is just a cosmetic thing, but it unfortunately isn't and the user is not warned about this fact!

When you change the name, the old library basically will be destroyed and a new one created (or something along this) and you will loose ALL related settings, metadata customization and configuration in all user accounts. So one has to re-enable library access for all user accounts and each user has to reconfigure it's startup page layout and what not. Not to mention the metadata fixes you might have done (not all changes might have been saved in the media folder itself for easy recreation but in a local Jellyfin cache folder instead, which will be killed as well).

Possible solutions/fixes:

a) Add a text warning to the rename dialog

As a short term "fix", a warning in the rename dialog about these severe implications should be added

b) Decouple the display name of a library from it's internally used name

Long term, the way libraries are stored and handled needs to be fixed/improved

  • use a UUID (or something like that) as internal name, which will be stored in the DB and be used as folder name on the filesystem.
  • add an additional display name field to the DB (or however this config is stored, not familiar with the codebase) and use it's value in the UI instead of the main identifier (UUID)
  • optionial: show the UUID to admins in the library edit dialog so that admins can still figure out the related filesystem folder in case one would have to tinker around in there for whatever reason

Jellyfin Version

10.8.0

if other:

No response

Environment

- OS: linux
- Virtualization: Docker
- Clients: Web
- Browser: Firefox

Jellyfin logs

No response

FFmpeg logs

No response

Please attach any browser or client logs here

No response

Please attach any screenshots here

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
Originally created by @da-anda on GitHub (Dec 1, 2022). ### Please describe your bug One might think that changing the name of a library is just a cosmetic thing, but it unfortunately isn't and the user is not warned about this fact! When you change the name, the old library basically will be destroyed and a new one created (or something along this) and you will loose ALL related settings, metadata customization and configuration in all user accounts. So one has to re-enable library access for all user accounts and each user has to reconfigure it's startup page layout and what not. Not to mention the metadata fixes you might have done (not all changes might have been saved in the media folder itself for easy recreation but in a local Jellyfin cache folder instead, which will be killed as well). ## Possible solutions/fixes: ### a) Add a text warning to the rename dialog As a short term "fix", a warning in the rename dialog about these severe implications should be added ### b) Decouple the display name of a library from it's internally used name Long term, the way libraries are stored and handled needs to be fixed/improved - use a UUID (or something like that) as internal name, which will be stored in the DB and be used as folder name on the filesystem. - add an additional `display name` field to the DB (or however this config is stored, not familiar with the codebase) and use it's value in the UI instead of the main identifier (UUID) - optionial: show the UUID to admins in the library edit dialog so that admins can still figure out the related filesystem folder in case one would have to tinker around in there for whatever reason ### Jellyfin Version 10.8.0 ### if other: _No response_ ### Environment ```markdown - OS: linux - Virtualization: Docker - Clients: Web - Browser: Firefox ``` ### Jellyfin logs _No response_ ### FFmpeg logs _No response_ ### Please attach any browser or client logs here _No response_ ### Please attach any screenshots here _No response_ ### Code of Conduct - [X] I agree to follow this project's Code of Conduct
OVERLORD added the bugstale labels 2026-02-07 00:48:41 +03:00
Author
Owner

@ristomatti commented on GitHub (Jan 3, 2023):

I also got bit by this after tediously manually identifying tens of movies stored on a cloud storage mount.

After playing around with Jellyfin for a while, I realized I can add both my local and remote folders under the same library. Initially I thought the initial scan would be too slow if I wanted to extract thumbnails from the remote files. It turned out to be fast enough to not warrant separate library for local files.

I then decided to delete my 1 folder local test library "Movies" to free the name for my cloud storage based library which I had already updated via manual identification. I figured this way I could avoid identifying them again, but instead lost all the metadata🤦.

@ristomatti commented on GitHub (Jan 3, 2023): I also got bit by this after tediously manually identifying tens of movies stored on a cloud storage mount. After playing around with Jellyfin for a while, I realized I can add both my local and remote folders under the same library. Initially I thought the initial scan would be too slow if I wanted to extract thumbnails from the remote files. It turned out to be fast enough to not warrant separate library for local files. I then decided to delete my 1 folder local test library "Movies" to free the name for my cloud storage based library which I had already updated via manual identification. I figured this way I could avoid identifying them again, but instead lost all the metadata🤦.
Author
Owner

@HimbeersaftLP commented on GitHub (Jan 4, 2023):

Seems to be the same issue as #2451

@HimbeersaftLP commented on GitHub (Jan 4, 2023): Seems to be the same issue as #2451
Author
Owner

@jellyfin-bot commented on GitHub (May 5, 2023):

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.

If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or master branch, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.

This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

@jellyfin-bot commented on GitHub (May 5, 2023): This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or master branch, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on [Matrix or Social Media](https://docs.jellyfin.org/general/getting-help.html).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#4395