Why does the .nfo file NOT always take precedence. Let me explain.
I want to change the title of a movie. I can adjust it in the DMS web app. It will then change in the web app and the DMS (if refreshed). So far so good.
However I notice that this info is NOT saved into the nfo file itself, which is where I would expect it to be.. The nfo file is still incorrect. I can even adjust the nfo file directly to ensure it has the desired change and save directly.
However if I rebuild the system, it appear to reload from the tmdb directly instead of the nfo file (which should take precedence) and seems to ignore the nfo file as I can still verify the nfo file has the corrected value. I have also determined that a fix-match correction will reload the nfo file from the tmdb and overwrite any corrections you have, but the rebuild doesn't affect this.
So In short any corrections via the DMS web app seem temporary until a rebuild is done and doesn't actually save to the nfo file. In addition - the nfo file will also be created by the system if it doesn't exist upon an initial fix-match or scrap, but after that it seems to be ignored. It appears the info is being populated and saved somewhere else, and the nfo file itself in my opinion should be in the end the primary source of information once populated and corrected.
However while I am "complaining" about this fact, about 1/2 of my renames have taken and do survive a rebuild with the corrected value. However many do not, and some appear to over time actually take and hold. It is spuratic in nature when the nfo file should take precedence.
TRJ
I want to change the title of a movie. I can adjust it in the DMS web app. It will then change in the web app and the DMS (if refreshed). So far so good.
However I notice that this info is NOT saved into the nfo file itself, which is where I would expect it to be.. The nfo file is still incorrect. I can even adjust the nfo file directly to ensure it has the desired change and save directly.
However if I rebuild the system, it appear to reload from the tmdb directly instead of the nfo file (which should take precedence) and seems to ignore the nfo file as I can still verify the nfo file has the corrected value. I have also determined that a fix-match correction will reload the nfo file from the tmdb and overwrite any corrections you have, but the rebuild doesn't affect this.
So In short any corrections via the DMS web app seem temporary until a rebuild is done and doesn't actually save to the nfo file. In addition - the nfo file will also be created by the system if it doesn't exist upon an initial fix-match or scrap, but after that it seems to be ignored. It appears the info is being populated and saved somewhere else, and the nfo file itself in my opinion should be in the end the primary source of information once populated and corrected.
However while I am "complaining" about this fact, about 1/2 of my renames have taken and do survive a rebuild with the corrected value. However many do not, and some appear to over time actually take and hold. It is spuratic in nature when the nfo file should take precedence.
TRJ