What is the use of nfo files?

[SenatorIvy 12]

ok so just so I'm clear on this, if I DONT use NFO's, any changes I make are still written to the local emby DB & used without it wanting to go scrape for info (unless info is missing, presumably) ?

[GrimReaper 3308]

Yes. 

[SenatorIvy 12]

Excellent.

[Carlo 4330]

1 hour ago, GrimReaper76 said:

Exactly. Nfos use is twofold:

1) Initial adding of an item (or Refresh) - once imported, has no use, you might as well delete it, and run server db only from there onwards

 

36 minutes ago, SenatorIvy said:

ok so just so I'm clear on this, if I DONT use NFO's, any changes I make are still written to the local emby DB & used without it wanting to go scrape for info (unless info is missing, presumably) ?

The NFO ensures any custom meta-data you've changed or edited along with proper ID is saved in the NFO.

There after if you ever have to reload the library you will get back exactly what you had in the database before.

[SenatorIvy 12]

OK that just put me back in the confused bin.  Why wouldn't custom metadata I change be entered into the db and just saved there?

[Carlo 4330]

7 hours ago, Happy2Play said:

Yes this will be overall library configuration, when I rebuild I disable everything so it only needs to read what already exists then enable things after the initial scan.  Otherwise a combination of reading and online fetching is done.

@Luke why is this?

If we have an NFO that contains all the information needed to populate the db and we have the local graphics why is any request made to a 3rd party meta-data provider? This does slow down library rebuilds and I'm not sure what it's actually trying to do.

If it's going to pull down new info or replace graphics that sort of defeats the purpose.

[Luke 37094]

3 minutes ago, cayars said:

@Luke why is this?

If we have an NFO that contains all the information needed to populate the db and we have the local graphics why is any request made to a 3rd party meta-data provider? This does slow down library rebuilds and I'm not sure what it's actually trying to do.

If it's going to pull down new info or replace graphics that sort of defeats the purpose.

To fill in missing data, such as cast images, or other things. For example, you might have enabled importing collections but your nfo doesn't have any set tags.

[SenatorIvy 12]

This is why I am confused as to the overall use; if there's a db it stores in and the db holds all custom-edited info as well, storing an nfo that then gets generally ignored seems superfluous.  I only noticed they were like this when re-scanning kept happening and it found new art.  I get that if it thinks a show is new it has to scan and read the file, but if the nfo is there and it's like "the poster is agabaga.jpg" I don't know why it then likes to either go "there's no art for this show" or "there is art, and it's bagabooga.png that I downloaded from the web instead of using what we had already"

[GrimReaper 3308]

3 minutes ago, SenatorIvy said:

OK that just put me back in the confused bin.  Why wouldn't custom metadata I change be entered into the db and just saved there?

It is, I assume @cayars wanted to quote 2) there.

To make it clear: use of nfos is completely optional. If you use them, it can be as a reader, saver or both. Depending on your needs, you will set that up acvordingly. 

However, ANY change you make is written in db. If you use nfo saver - it will be written there. If you don't - you will not have any backup if you need to restore, you will have to rescrape everything. 

[SenatorIvy 12]

And in the realm of backups, the db is somewhere in the root emby folders right? like if I run emby from C:\Emby by default the db is somewhere in the C:\Emby folders? Just so I know, I dont wanna be surprised later to find out that it's actually in appdata or somewhere.

[Happy2Play 8296]

1 minute ago, SenatorIvy said:

This is why I am confused as to the overall use; if there's a db it stores in and the db holds all custom-edited info as well, storing an nfo that then gets generally ignored seems superfluous.  I only noticed they were like this when re-scanning kept happening and it found new art.  I get that if it thinks a show is new it has to scan and read the file, but if the nfo is there and it's like "the poster is agabaga.jpg" I don't know why it then likes to either go "there's no art for this show" or "there is art, and it's bagabooga.png that I downloaded from the web instead of using what we had already"

NFO are more of a backup.  If your need to rebuild or your database breaks/corrupts you are not starting from scratch as a new database is a empty database.

1 minute ago, SenatorIvy said:

And in the realm of backups, the db is somewhere in the root emby folders right? like if I run emby from C:\Emby by default the db is somewhere in the C:\Emby folders? Just so I know, I dont wanna be surprised later to find out that it's actually in appdata or somewhere.

Emby installs to user appdata unless you are running a portable install then it is where ever you put it.  Technically you can move Emby to where every you like in Windows but you do not have a choice in the installer.

[SenatorIvy 12]

I've got mine going from a portable install, so as long as I'm periodically backing up that folder I guess I'm good.  With the rate of rescans time with the nfos being what it is already I will just run the risk, lol :v

[Carlo 4330]

What risk?

[GloverEggs 6]

3 hours ago, GrimReaper76 said:

Exactly. Nfos use is twofold:

1) Initial adding of an item (or Refresh) - once imported, has no use, you might as well delete it, and run server db only from there onwards

And/Or

2) Backup purpose - any subsequent change in Item metadata will be written to nfo (if nfo saver enabled), hence ensuring you will not need to rescrape/redownload everything upon db corruption or library rebuild. 

 

How do you enable NFO Saver?

[Carlo 4330]

Have you explored your Library settings?

[GrimReaper 3308]

3 minutes ago, GloverEggs said:

How do you enable NFO Saver?

Edit any Library settings, there's Metadata Reader field above all meta-providers listed, and Metadata Saver section below them. 

[GloverEggs 6]

Thank you!  I hadn't noticed that before.  I don't have an automatic backup of my media so I keep copies on another computer.  This will help tons!

[SenatorIvy 12]

2 hours ago, cayars said:

What risk?

The risk of losing my db and needing to rescan everything, which takes forever, vs storing a bunch of nfos everywhere that mess me up that, if present, cause the rescan/rebuild process to be only slightly less than forever.  Better to just risk the few differences between regular backups than have to deal with nfos everywhere.

[Carlo 4330]

The point of the NFO is to remove the risk of not restoring the meta-data back the way you had it previously. Without the NFO & graphics stored with your media (same for bif/thumbnails) you would loose any custom meta-data edits, would loose any custom collections, would loose any artwork you've switched/changed and would have to rebuild the thumbs (if using).

It's far better for most people to write this info to the movie/show folder so in the event of a rebuild you get back what you had previously vs starting from scratch.

The storing of NFO files certainly doesn't mess up reloading this data and these have nothing to do with conventional backups.

To me it seems you got things backwards are far as risk is concerned.

[SenatorIvy 12]

OK we seriously need clarification on this entire system, because this makes no sense.

There is a database.  This database is something we can (I assume) edit every field of via the metadata manager, customizing the metadata to the same level that you could if you were using NFO files.

If I am regularly backing up that database, that means a rebuild would consist of simply restoring the working DB, which entails far less potential for rescans.

If the risk we are talking about is the theoretical loss of the database, having a backup of the database itself that the app would have nothing to do to continue using is a better backup solution than having thousands of files that need parsing to recreate a database.  A theoretical full mirrored set is always going to be preferable to a parity approach.

I am understanding the whole "you would lose all of your custom edits if something happened to your database and you didn't have the NFO files," because the changes you make are written to both the db and the NFO files, and then on the theory of rebuilding a library, someone without NFO files would only get what is scraped from the internet, and someone with the NFO files would get what is scraped from the internet, and then also their customizations.  What I'm saying is this has never been what happens for me.  I have had plenty of custom info in NFO files that, on rebuild, was ignored entirely.  Posters, titles, actors I had added because for whatever reason the scrape didn't grab them, etc etc.

 

I'm not against keeping NFO files as a secondary, I just dont want them in the folders with the media.  If there's a way to make emby create an NFOs folder in its root and store the NFOs there instead that would be ideal.  My whole issue is where they're stored and why they never seem to get used as a source when I have to rebuild.  I feel like if there was a log or console we could see in the server tools area that let us watch to a fine grain what the scanner was doing this would be better.  As it is a scan call is like not scanning -> 93% -> 95% -> not scanning -> 90% ->93%->done.  Presumably this is the identifying pass and then the scraping/parsing pass, but just having to wait through and guess what the timeline of it is is what's got me on this.  The only insight we get into the scanning process on the server page is the blue bar for progress which might be fine at a glance, but I think it would be nice if there's multiple parts of the engine for that like scanner/scraper/parser that we could have a status shown for each part so we could know what was going on and what was being done when.  That way I could look at a log of a parser and see why it's grabbing a new image instead of using the one I've got existing, etc etc.

[GrimReaper 3308]

4 minutes ago, SenatorIvy said:

There is a database.  This database is something we can (I assume) edit every field of via the metadata manager, customizing the metadata to the same level that you could if you were using NFO files.

Correct, more or less. Not all db fields are exposed in the UI, but you can check all of them in a db editor. NFOs usually have several more of those fields written than presented in the UI, but they are in the db anyway. 

7 minutes ago, SenatorIvy said:

If I am regularly backing up that database, that means a rebuild would consist of simply restoring the working DB, which entails far less potential for rescans.

If the risk we are talking about is the theoretical loss of the database, having a backup of the database itself that the app would have nothing to do to continue using is a better backup solution than having thousands of files that need parsing to recreate a database.  A theoretical full mirrored set is always going to be preferable to a parity approach.

1:1 on Emby folder should be sufficient for backup purposes. Keep in mind it works for same server version only, due to db changes introduced with any new version. So, if you ever wanted to start with new server version, you'll have to do it from scratch. 

10 minutes ago, SenatorIvy said:

because the changes you make are written to both the db and the NFO files, and then on the theory of rebuilding a library, someone without NFO files would only get what is scraped from the internet, and someone with the NFO files would get what is scraped from the internet, and then also their customizations.

Partially correct, someone with NFO would get all that is written in NFO, and depending on your meta-provider settings, something scraped (if those enabled) or nothing scraped (if those disabled). 

13 minutes ago, SenatorIvy said:

If there's a way to make emby create an NFOs folder in its root and store the NFOs there instead that would be ideal.

There is not. NFOs are not exclusive to Emby, nor they are proprietary, - it's more like they are Kodi proprietary. Kodi dictates the rules. And they prefer it this way. 

[GrimReaper 3308]

On 8/14/2021 at 11:55 AM, GrimReaper76 said:

That depends on one's particular setup. Mine is strictly nfo-driven, i.e. all Emby's internal meta-scrapers disabled, Emby is practically a front-end only with TMM as back-end. Rebuild with all local nfos+artwork+trailers for approx. 4,000 movies/20,000 episodes usually takes under an hour on main server, few hours on portable one. 

 

On 8/14/2021 at 12:32 PM, Happy2Play said:

Yes this will be overall library configuration, when I rebuild I disable everything so it only needs to read what already exists then enable things after the initial scan.  Otherwise a combination of reading and online fetching is done.

 

On 8/14/2021 at 12:34 PM, GrimReaper76 said:

I even completely kill the internet connection while doing it.

 

27 minutes ago, SenatorIvy said:

My whole issue is where they're stored and why they never seem to get used as a source when I have to rebuild.

You can very easily confirm what was written above: make a folder with few items only, that contain only media file and local nfo+artwork, make a Library that has all meta-providers disabled (unselect literally all metadata and image fetchers), leave only Nfo reader enabled. Check how long it will take you to scan and populate that Library. Likely single-digit minutes. 

Edited August 15, 2021 by GrimReaper76
Typo

[Carlo 4330]

29 minutes ago, SenatorIvy said:

OK we seriously need clarification on this entire system, because this makes no sense.

There is a database.  This database is something we can (I assume) edit every field of via the metadata manager, customizing the metadata to the same level that you could if you were using NFO files.

If I am regularly backing up that database, that means a rebuild would consist of simply restoring the working DB, which entails far less potential for rescans.

So let me ask you this.  Let's say your movies are stored on Drive E but you need to move them to Drive F or you want to move them to a NAS or other file server as your storage requirements increase. 

What then?  Without the NFO you will be deleting the old records from the database and adding new records.  Doesn't matter which order this happens in but you lost all your customizations.  With the graphics, bif, NFO files in the media folder the new scan will pick them right up and all custom info is preserved.

NFO aren't just about backup of meta-data but make running the Emby Server easier when changes to storage are needed as well.

Edited August 15, 2021 by cayars

[SenatorIvy 12]

I guess I don't see why Emby shouldn't have a secondary option that moves the NFOs solely because other apps use them.  Like ok great for those other apps, and if I use those I'll be sure not to enable the "keep NFOs in separate folder in Emby root" option, but if I'm only ever using them for Emby and Emby's needs I feel like having them in an Emby-only folder doesn't seem like an outlandish usage, especially if they're being touted as practically essential for best-practices operation.

[Carlo 4330]

Because if it isn't broken "don't fix it".  Other programs from writers like Tiny Media Manager to front ends such as Kodi expect the NFO file to be in the same folder as the media.  NFO isn't an Emby invention but is used by many platforms so Emby needs to follow the spec of how they are suppose to work so they are compatible with other systems.

Building on that you want all info to be "portable" so graphics, thumbs, chapters, external subtitles, main media all move together when you move the folder.

Edited August 15, 2021 by cayars