Reply to thread

Message: <blockquote data-quote="MJGraf" data-source="post: 1165330" data-attributes="member: 17886">Hi resa,In general, I tend to agree. But there are a few "buts":<ul> <li data-xf-list-type="ul">The most important word in your statement for me is "on-demand". I would never want any Media Application to automatically generate nfo-files in my media collections (or even worse, let it automatically overwrite any nfo-files that were already there before).</li> <li data-xf-list-type="ul">The operation of generating nfo-files should ideally be a one-time task. Once you have generated an nfo-files from locally or online available information, you may want to manually edit the nfo-file. But after you have manually edited the nfo-file, you will probably not want your edits to be overwritten by a newly generated nfo-file. As a result, I don't think the operation of generating nfo-files should be part of a Media Center Application such as MP2, which is supposed to be used with a remote control. Generating nfo-files is closely related to making edits to them and the latter one is definitely a task for a separate application (of which there are already a lot: MP2Edit, TMM, EMM, etc.).</li> <li data-xf-list-type="ul">Nevertheless, I think MP2 should support this - but IMHO not from the MP2-Client application, but via a Web Interface. I'm still dreaming of a web server built into MP2-Server with a web-frontend that you can just open with your browser. On that web-frontend, you should be able to do a lot of things such as Configuring MP2-Server, maybe watch or listen to the media in your MediaLibrary via streaming, but also just browse through your MediaLibrary and make changes to the metadata. Once you are fine with the metadata that was either previously fetched by our MetadataExtractors or manually edited in the MediaLibrary, I would imagine that on right-click on a MediaItem (or for batches on a parent folder), you get the option wo "generate a nfo-file". Only downside is: There is still a long way to go until we are there... But the good news is: I'm willing to go that way - it may just take a while...</li> </ul>Oh and you can believe me, there is nothing in the respect that I would support more. But I wouldn't hold my breath...I have no clue who first "created" nfo-files - it might have been Kodi. The issue with nfo-files is that they, as they are now, look like they are based on another standard. But in fact they are not. As an example: Nfo-files look like they are XML-files. But actually they are not. The "standard" for a nfo-file belonging to a video file with multiple episodes of a series is that the nfo-file has multiple <episodedetails> root elements. The xml standard does not allow multiple root elements, which is why any xml-parser out there throws an error when reading such files (and why I had to write our own XmlNfoReader class...).Another example is what we are dealing with in this thread: Kodi allows nfo-files just with a link to the imdb webpage of a movie in it. This has nothing to do with xml. And even worse, AFAIK, Kodi also allows part of the nfo-file to contain (kind of) xml and at the end have a link to imdb so that you can take metadata from imdb first and "overwrite" part of it via xml.To cut a long story short: IMHO an nfo-standard should be based on a document standard and follow this standard 100%. If this is not the case (as currently), there will never be a "real" standard because no matter which programming language a media application uses, you cannot use the standard tools of this language to read it and it will always be a lot of manual work (as it was here with MP2). As long as there is manual work involved, there will always be deviations from implementation to implementation.But even if the programmers of different media applications would agree upon a "new" standard for nfo-files, this would mean that the implementations of all such programs would have to change completely and this I would consider unlikely...</blockquote>

Verification