Page 1 of 1

Jellyfin compatible naming scheme : nfo

Posted: 28 Sep 2025, 00:07
by smellycheese
Hi,

Following main thread (Jellyfin compatible naming scheme) here is fifth part of the main idea related to nfo files.

For each file, I want an nfo file, in destination folder, named as the movie file but with .nfo extension.
This nfo must be compatible with Emby/Jellyfin and include the following informations :

original title
year
imdb tag
tmdb tag
sha256 (or any other relevant hash to retrieve file in case of filename mismatch between movie file and nfo file)
file size in bytes
original filename

I'm aware that hash will significantly extend processing time.
I considered post-processing this by adding the hash via another script, but while the initial processing will take a long time, the additions should be very quick.

Thank in advance

Re: Jellyfin compatible naming scheme : nfo

Posted: 28 Sep 2025, 03:40
by rednoah
The Export NFO files post-processing feature will take care of most of these things, and create NFO files like this:

XML: Select all

<?xml version="1.0" encoding="UTF-8"?>
<movie>
    <uniqueid type="tmdb">19995</uniqueid>
    <title>Avatar</title>
    <originaltitle>Avatar</originaltitle>
    <sorttitle>Avatar Collection :: 2009-12-15 :: Avatar</sorttitle>
    <year>2009</year>
    <premiered>2009-12-15</premiered>
    <mpaa>PG-13</mpaa>
    ...
    <set>
        <name>Avatar Collection</name>
    </set>
    ...
    <country>US</country>
    <country>GB</country>
    <studio>Dune Entertainment</studio>
    <studio>Lightstorm Entertainment</studio>
    <studio>20th Century Fox</studio>
    <studio>Ingenious Media</studio>
    ...
    <director>James Cameron</director>
    <credits>James Cameron</credits>
    <fileinfo>
        <name>Avatar (2009).mkv</name>
        <size>355660657</size>
        <streamdetails>
            <video>
                <codec>x264</codec>
                <bitrate>1622271</bitrate>
                <width>640</width>
                <height>480</height>
                <aspectratio>4:3</aspectratio>
                <framerate>24.000</framerate>
                <scantype>Progressive</scantype>
            </video>
            <audio>
                <codec>AC-3</codec>
                <bitrate>192000</bitrate>
                <language>eng</language>
                <channels>2</channels>
                <samplingrate>48000</samplingrate>
            </audio>
            <audio>
                <codec>AC-3</codec>
                <bitrate>192000</bitrate>
                <language>jpn</language>
                <channels>2</channels>
                <samplingrate>48000</samplingrate>
            </audio>
            <subtitle>
                <codec>UTF-8</codec>
                <language>eng</language>
            </subtitle>
            <subtitle>
                <codec>UTF-8</codec>
                <language>jpn</language>
            </subtitle>
            <subtitle>
                <codec>VobSub</codec>
                <language>eng</language>
            </subtitle>
            <subtitle>
                <codec>VobSub</codec>
                <language>jpn</language>
            </subtitle>
        </streamdetails>
    </fileinfo>
    <tmdb id="19995">https://www.themoviedb.org/movie/19995</tmdb>
    <imdb id="tt0499549">https://www.imdb.com/title/tt0499549</imdb>
</movie>
:!: The file will be named movie.nfo. Renaming movie.nfo ➔ Avatar (2009).nfo would be a very simple custom post-process.

:!: The default XML includes everything EXCEPT the original filename and the sha256 hash.

:arrow: The easy solution would be a separate Custom Post-Processing Scripts akin to Generate SFV files that. Writing extra information to a new separate XML file is very easy. If you want to inject that information into the existing XML file, then that's possible of course but a lot more tricky.

:idea: The alternative to that is to just have your own code generate the entire XML file the way you want from scratch. That way you have full control over every element of the NFO / XML file structure, the file name, etc. That would make sense if you're happy with a simplified NFO / XML file that doesn't add as much information as the default built-in NFO / XML generator.

:idea: Regardless of the implementation details we come with up in the future, any post-processing script fundamentally can run on demand if you don't want to run it as part of the Rename process.

Re: Jellyfin compatible naming scheme : nfo

Posted: 28 Sep 2025, 14:13
by smellycheese
Hello,

Let's go for the existing process for generating NFO.
For the sha256 I'll take care of this myself, I'm even not fully decided for the hash type (sha256 could be very slow) and asked for this one as it still common.
On a post process work, I'll have more option.

For the original filename, that's more a problem.
I'm looking for this information not because I'm not confident in filebot, but for other purpose.

Other option, I maybe can have the original filename from a (filebot) log ?
If so I can include it to the nfo on post process script, but I'm not sure that information is available on a text format.

Thank in advance

Re: Jellyfin compatible naming scheme : nfo

Posted: 28 Sep 2025, 18:12
by rednoah
smellycheese wrote: 28 Sep 2025, 14:13 For the original filename, that's more a problem.
I'm looking for this information not because I'm not confident in filebot, but for other purpose.
:arrow: The original file name is readily available via xattr metadata as part of the file system entry:

powershell: Select all

Get-Content 'Alias - S01E01 - Truth Be Told.mkv' -Stream 'net.filebot.filename'
Screenshot


:arrow: Alternatively, you can query the History for all previous rename operations:

Shell: Select all

filebot -script fn:history



smellycheese wrote: 28 Sep 2025, 14:13 I'm even not fully decided for the hash type (sha256 could be very slow) and asked for this one as it still common.
FileBot can calculate CRC32 / MD5 / SHA1 / SHA2-256 / SHA3-384 hashes. If you just want to check for file corruption then CRC32 / MD5 is probably good enough. If you mean to uniquely identify files then SHA2-256 should be plenty entropic to not run into hash collisions with just a few ten thousand files.