Change NFO Location

[METALHEAD]

I think it would be nice to choose a folder where these NFO files are stored or used by Jellyfin Server.
As of right now, they are stored in the same location as the media file which adds clutter within my folders.

[Nachtigaller]

I totally agree but the feature request never caught on and now we're stuck with this not ideal solution.
It's also not just about clutter but also a problem if denying Jellyfin write permissions to the media directory which prevents it from deleting your stuff if it feels like it. Meanwhile the best option for purely manually added metadata is clicking the three dots, edit metadata, do your stuff and save which is horribly slow and can't be backed up separately which is unfortunate.
So all in all I'm with you thinking it would be nice and hope that it'll get implemented one day.

[TheDreadPirate]

If you are using Jellyfin why would it matter if the media directory is "cluttered" with images and NFO files?  You don't see the "clutter" since you are viewing your media with Jellyfin.

Since the media path is not part of the metadata in an NFO, how would Jellyfin make the initial connection between the NFO and the media if it isn't co-located with the media?  Additionally, the point of NFOs is easy metadata portability.  Having it in a separate directory partially negates that portability.  But let's say that NFOs did have the media path and were consolidated in one directory.  That's a separate directory you now need to migrate if you change media streaming platforms.  Or if you are shuffling your media around or remounting a hard drive, now the NFO is useless as is.  You would need to modify all your NFO files.

You can grant Jellyfin write permissions to a directory, but only grant read permissions to your media files.  Jellyfin then can write images and NFO files, but can't delete the media and, because the directory still has media, won't be able to delete the directory.   I wrote a short bash script to automate this when I add new media.

For the record, Jellyfin will only delete your media if you tell it to or you misconfigure something.  One example misconfiguration is if you co-locate your Jellyfin cache with your media.  Not sure why you would do this, but someone did do this and found out the hard way that there is a scheduled job that recursively deletes the cache directory.

[Nachtigaller]

In case anyone with the same problem and nothing against some tinkering stumbles across this: I got the media and nfo files separated by merging media, nfo (and cover/art/poster) folder via mergerfs into a fourth folder Jellyfin accesses. I write my nfo files with external programs and move them to the correct location in the nfo folder tho so I don't know where they would be saved if Jellyfin wrote and saved them in the merged folder.

While it's only a workaround, TheDreadPirate made some good points why an option to change the nfo location in Jellyfin itself might never be implemented I didn't know/thought about but so far it works really well for my use case.

[roycrt]

How about tagging the nfo and bif files with something like
/path-to-movie/movie/movie_jf.nfo
/path-to-movie/movie/movie_jf.bif
I'm new and am trying jellyfin along with my old emby stuff.
I think a lot of new users would like to have them both, or some other program share the media folder. Pictures are pictures
It easy to set permissions at 664 for folders and 644 for media files

Or create a sub-folder
/path-to-movies/movie-folder/metadata
I sort of remember that being an option several years ago.

[CleverId10t]

You can grant Jellyfin write permissions to a directory, but only grant read permissions to your media files.  Jellyfin then can write images and NFO files, but can't delete the media and, because the directory still has media, won't be able to delete the directory.   I wrote a short bash script to automate this when I add new media.

It would be great if you could provide that script (-:

[roycrt]

With Linux
sudo find /path-to-media-directory/media-directory-name -type d -exec chmod 664 {} \;
sudo find /path-to-media-directory/media-directory-name -type f -name "*.mkv" -exec chmod 644 -f "{}" \;
sudo find /path-to-media-directory/media-directory-name -type f -name "*.mp4" -exec chmod 644 -f "{}" \;
sudo find /path-to-media-directory/media-directory-name -type f -name "*.m4v" -exec chmod 644 -f "{}" \;
sudo find /path-to-media-directory/media-directory-name -type f -name "*.avi" -exec chmod 644 -f "{}" \;

Just make sure jellyfin is a member of the directories group or be safe and do this instead of 664
sudo find /path-to-media-directory/media-directory-name -type d -exec chmod 666 {} \;

Not sure if jellyfin needs execute authority. Maybe someone will chime in on that. If it does then make directories permission 777
sudo find /path-to-media-directory/media-directory-name -type d -exec chmod 777 {} \;

example
sudo find /srv/Movies -type d -exec chmod 777 {} \;

[TheDreadPirate]

For directories you ALWAYS need execute permissions. When you "cd" to a sub folder "cd" is technically executing something.

So your first find with "type d" should be 755 or 775 if you need write permissions for the group owner.

[thornbill]

Please note that posts to the feature requests section on this forum are only meant to provide means of discussing existing requests on features.jellyfin.org and a link to that request should be included in the post. Thanks!

https://forum.jellyfin.org/t-please-read...s-to-fider

[roycrt]

Thanks for clarifying TheDreadPirate. I personally use 770 for directories because emby needs execute. Was never sure why

Any feedback on an option to choose storing metadata into a sub-directory of the media directory. .../Matrix/metadata

I think the idea of keeping metadata in media directory is best. For me, wanting to try jellyfin with emby already installed and wanting to keep my watched list, I had to install emby in a new docker container and choose not to store metadata in media folder.
I then had to delete all nfo and image files. Then do a complete re-scan and import my user data for all users. PITA