home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 2
General
this view could not be built
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="resa" data-source="post: 1165415" data-attributes="member: 68500"><p>Agreed, and therefore i was using the words on-demand <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> Including my response for some of the following points on your list too, let me go into detail right here... Logically there should be 2 or more different situations for generate the nfo's, but the first one should be enough at least for the experienced useres (and the first situation represents how far the Kodi-Devs has gone until now):</p><p></p><p>1. Export the whole library into seperate .nfo-files: Will export the whole library into seperate video-filename.nfo where each is written to the the same location of the video-filename.avi/mkv/.... as said already. Before starting this Process, there MUST be the question what to do with items that already have existing nfo's - should the nfo's be overwritten or should export for those items to be skipped? Along with an super-clear instruction for overwriting meaning that the current data stored in the library is used to overwrite and the user have to be absolutely sure, that the data in the library is currently correct for each and every item. This option can be used as globally function when i.e.: Initially saving the nfo's after the first bunch of items was added to the library (answering overwrite or skip). Each time the User has made numerous personal alterations to the data and is sure, that all data for all items in the library is currently correct (answering overwrite). Each time the User has added the next bunch of items to the library and made no alterations to existing items or is unsure if all data for existing items in the library is currently correct anymore (answering skip). Correcting the content of nfo's for already exported items after the items data is updated in library and the existing nfo is deleted (asnwering skip). And so on...</p><p></p><p>[To give you the complete information: the complete library export in Kodi can be done either to seperated nfo's written to video-filename location as we are talking here about OR into one single xml containing the data for all the items in library together, what is somewhat intransparent and almost counteracts the idea for use as a backup, fallback-backup and exchange format since all the data in library should never be damaged partly or similar mess (for not needing to paste data from different xml's together manually some day). Also having more disadvantages like the need to include the physical file location, hampering to move the files to another location and easily reimport the data using the nfo's and so on and on.]</p><p></p><p>2. For more convienient usability there should be also the ability to export the nfo for the marked single item or multiple marked items from within list views, after the same MUST BE question along the instruction mentioned above already. And in an optimal world the user also be asked for saving/updating the changed data into nfo-file every time the user has re-scraped the item data or have opened the detail view of an item and altered the content of one or more fields in there (i.e. altering title, sorting title, description etc. like many users love to do for several reasons, as far as i have learned), this can be worked out either with the use of an checkbox "generate/update nfo-file on leaving/approval" or also with an option in the main settings to supress those question for the users who dont want to use the nfo's in general.</p><p></p><p>Additionally there should be functions to generate nfo's after user/auto-approval of scraped data for new items and maybe to generate all the nfo's only for the specified paths with or without processing it's subfolers... and so on... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> The more functionalities you have handy within MePo, the more it will be an one-time task without any accidents. Kodi lacks of more flexible options here, alltough the ground idea is somewhat great <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>Fully equipped with that functions and understoodable communicated to the user within the gui's even the unexperienced users should notice the purpose of the nfo's no matter if placed within an WPF-like configutil as seen on MePo1's Videos/MovingPictures or placed within the frontend. I am currently not really aware how editing the the media-librarys in MePo2's has to be done, i wasen't enough satisfied to go that deep into the details during my tryouts on MePo2 until now, but to add/edit/rescrape a single or some few items was always be mission possible to do with the remote (and on other hand: who the heck is wasting all the full PC abilities and has not at least something like the thirty-bucks Logitech K400 attached and is hiding it by sliding this under his sofa?!?!? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /> )</p><p></p><p>But i double agree, the idea to do all the configurations on client, server and plugins from smartphone/tablet using an web-interface from the sofa is a charming one <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> also doing all the settings and details within the ir-remotable frontend like realised in Kodi is somewhat terrifying and anoying. MePo1 fully scores here with it's WPF-like configs <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> </p><p></p><p></p><p></p><p>This is good to hear about and let me assure you that you are not the only dev on an topic related project that have an open ear for this... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p></p><p></p><p>I am not abselutely sure, if this was initiated from XBMC or not, but i think the whole thing is already sort of beginning standard already. As far as i have looked over it, the XML seems to be simple and valid XML and seems also to not beeing changed over an long time. The XMLs generated by an current Kodi-Version is understood by i.e. an scraper delivered with MePo1's MovingPictures called XBMC(Local) wich was published on 23.07.2011 - more than 4 years ago and the data is still well imported, since every plugin on other projects, dedicated to import Kodis SQLite dbase get broke nearly on every version the Kodi devs are releasing dure to altered tables and variables and so on. Furthermore Emby Media Server seems to handle this nfo's but is at least generating nfo's using all the same tags, as i noticed on a first overlook. Conclusion: There are already 4 projects that supports this specific nfo' format ... and that is only what i know so far (but i will check all other topic relevant projects for that too in the future).</p><p></p><p>I hope this ins't interfere with forum rules if i post a link into Kodis WIKI for an brief description into this spoiler:</p><p></p><p>[SPOILER="Mod: please remove if interfere with forum rules."]<a href="http://kodi.wiki/view/NFO_files/movies" target="_blank">http://kodi.wiki/view/NFO_files/movies</a>[/SPOILER]</p><p></p><p></p><p></p><p>OK, but this class is already there? So this should not be that big deal anymore <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> And: I will not swear on it, but as far as i remember even Wordpress is using XML-Files sturctered in that way for importing/exporting new posts and even edits from external clients and i think for exchanging the pingbacks with other Blog/CMS/Forum-Systems too. Also this structure is used within Kodis movie nfo's for streaming-details (sort of media-info of the videofile) and in the tvshow.nfo too (which is placed into the series mainfolder and contains the infos about the series in general)... One thing to add may will be an additional scrape thetvdb for the season-related infos whilst import the nfo's of episodes from this season.</p><p></p><p>Much more complex seems to be the handling of dynamic data in the nfo's... the only that comes to my mind here is the view-count... but this value should be synchronized between library and .nfo in an reliable way and should be waive external things like trakt and also be easy to setup (kodi needs an extra plugin as well as some system-settings and on top you need to edit a XML config-file manually to get this working, i think you guys on MePo could perform better on this issue easily <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /> ) ... Maybe parted movies (bla-a.avi, bla-b.avi or bla-CD1.avi, bla-CD2.avi, i.e. Kodi responds on -CDx and perform generate nfo onto file CD1 only and also span the parts at playback) will make extra work... or movie-collections/series/sets and things like that. But at all, it wcould be not that big problem in order to make use of these nfo-format</p><p></p><p></p><p></p><p>I think we could ignore on this. It seems this was intended to have more flexibility in handing over goal-orientaed informations to the scraper, mainly this was implemented to easily make use of an completely different kind of files that wears the extension .nfo too i think. (Meaning those ascii-files which are mostly attached to video files released by <the-part-of-internet-we-dont-talking-about-in-here> and that are containing not many usefull informations, except an imdb-link or tt-number mostly <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> ). As you said, you drag and drop the folder you have extracted from some .rars onto your video-archive disk, letting kodi pick the imdb-link/tt-number to scrape with and after scraping you replayce this .nfo with kodis .nfo filled with the whole XML data <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p></p><p></p><p>So we have at least 4 projects working with this standard, and to repeat that, that seems to be not changed since years in general terms. I also cann not see the problem, if there are projects using some own specific tags in addition to the universal used tags, since you not have to process on every tag and can skip unknown tags. Also it is free for any project to skip some universal tags in order to generate these information by itselfs, i.e. media-information or something like that. Important for the User are only the tags like title, sorting-title, plot, outlin and some more. On tags like actor or writer the number of user that is altering content here will be much more smaller already. Importing the nfo also dosen't say, that there should be none additional scraping tasks added to fulfill the needs of the project i.e. for fill up some specific art-work that is used, only to NOT leave content altered by the user untouched is an no-go.</p><p></p><p></p><p></p><p>I cannot agree here, since structure of the nfo's looks like valid XML to me and is used by other serious applications that way too. It also reflects exactly the example that is shown on wikipedia at all (not that this is an measurement to me, i only say<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /> ). Dunno, but we are talkin about VS here, right? I am a bit out of practice. But at least i would be able to fire up free VS-MistressEdition and handle this like simplyfied noobish text "parsing" in the way of searching for the tags and cut the text between them, pushing this into vars in order to write this down to an dbase, if this would not be that totally Mr. Dumbiverse code of the year it would be then <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /> </p><p></p><p></p><p></p><p>I can not get your point here, it all counts down on the major tags never to be changed. How this is implemented, processed, sourrounded by additional things and turning out in any project or not - all this is fully decided by an projects dev-crew on their own behalf. Only the tags have to be keeped the same.</p><p></p><p></p><p></p><p>Seems like standard is already there and working fine. Why not simply using the power of 4 Projects (remember there are maybe already more) to coalesce on this as an exchange format? The only thing to do is fixing this existing standard tags to be sure it remains unchanged during the next years (unchanged means here: never alter an existing tag, only add new tags and let old tags simply dieying, so it is compatible downwards at any time without blocking new developments). But in the end i am sure, that this nfo's will work the next years if there is an coalition or not. This was only an additional improvment that i was suggesting with this. The Important thing is to make it possible, that at least MePo2, better also MePo1 can import these nfo's generally for the users that want to switch from another project to MePo or using multiple projects simultaneousely, that was my major point <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>But don't think my vision stops with the nfo's ... did you know that Kodi and the 3 other projects can im/export artwork in an format like videofilename-poster.jpg, videofilename-thumb.jpg etc. too? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p></p><p>No no, dont be afraid, now i am done here this time <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>If any of the devs like further informations i can link to more infos as well as to nfo's with real sample-data for movies and tv shows, please PM me in that case <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>Thanks for discussion and your interrest, with all the very best regards.</p></blockquote><p></p>
[QUOTE="resa, post: 1165415, member: 68500"] Agreed, and therefore i was using the words on-demand ;) Including my response for some of the following points on your list too, let me go into detail right here... Logically there should be 2 or more different situations for generate the nfo's, but the first one should be enough at least for the experienced useres (and the first situation represents how far the Kodi-Devs has gone until now): 1. Export the whole library into seperate .nfo-files: Will export the whole library into seperate video-filename.nfo where each is written to the the same location of the video-filename.avi/mkv/.... as said already. Before starting this Process, there MUST be the question what to do with items that already have existing nfo's - should the nfo's be overwritten or should export for those items to be skipped? Along with an super-clear instruction for overwriting meaning that the current data stored in the library is used to overwrite and the user have to be absolutely sure, that the data in the library is currently correct for each and every item. This option can be used as globally function when i.e.: Initially saving the nfo's after the first bunch of items was added to the library (answering overwrite or skip). Each time the User has made numerous personal alterations to the data and is sure, that all data for all items in the library is currently correct (answering overwrite). Each time the User has added the next bunch of items to the library and made no alterations to existing items or is unsure if all data for existing items in the library is currently correct anymore (answering skip). Correcting the content of nfo's for already exported items after the items data is updated in library and the existing nfo is deleted (asnwering skip). And so on... [To give you the complete information: the complete library export in Kodi can be done either to seperated nfo's written to video-filename location as we are talking here about OR into one single xml containing the data for all the items in library together, what is somewhat intransparent and almost counteracts the idea for use as a backup, fallback-backup and exchange format since all the data in library should never be damaged partly or similar mess (for not needing to paste data from different xml's together manually some day). Also having more disadvantages like the need to include the physical file location, hampering to move the files to another location and easily reimport the data using the nfo's and so on and on.] 2. For more convienient usability there should be also the ability to export the nfo for the marked single item or multiple marked items from within list views, after the same MUST BE question along the instruction mentioned above already. And in an optimal world the user also be asked for saving/updating the changed data into nfo-file every time the user has re-scraped the item data or have opened the detail view of an item and altered the content of one or more fields in there (i.e. altering title, sorting title, description etc. like many users love to do for several reasons, as far as i have learned), this can be worked out either with the use of an checkbox "generate/update nfo-file on leaving/approval" or also with an option in the main settings to supress those question for the users who dont want to use the nfo's in general. Additionally there should be functions to generate nfo's after user/auto-approval of scraped data for new items and maybe to generate all the nfo's only for the specified paths with or without processing it's subfolers... and so on... ;) The more functionalities you have handy within MePo, the more it will be an one-time task without any accidents. Kodi lacks of more flexible options here, alltough the ground idea is somewhat great ;) Fully equipped with that functions and understoodable communicated to the user within the gui's even the unexperienced users should notice the purpose of the nfo's no matter if placed within an WPF-like configutil as seen on MePo1's Videos/MovingPictures or placed within the frontend. I am currently not really aware how editing the the media-librarys in MePo2's has to be done, i wasen't enough satisfied to go that deep into the details during my tryouts on MePo2 until now, but to add/edit/rescrape a single or some few items was always be mission possible to do with the remote (and on other hand: who the heck is wasting all the full PC abilities and has not at least something like the thirty-bucks Logitech K400 attached and is hiding it by sliding this under his sofa?!?!? :D ) But i double agree, the idea to do all the configurations on client, server and plugins from smartphone/tablet using an web-interface from the sofa is a charming one ;) also doing all the settings and details within the ir-remotable frontend like realised in Kodi is somewhat terrifying and anoying. MePo1 fully scores here with it's WPF-like configs ;) This is good to hear about and let me assure you that you are not the only dev on an topic related project that have an open ear for this... ;) I am not abselutely sure, if this was initiated from XBMC or not, but i think the whole thing is already sort of beginning standard already. As far as i have looked over it, the XML seems to be simple and valid XML and seems also to not beeing changed over an long time. The XMLs generated by an current Kodi-Version is understood by i.e. an scraper delivered with MePo1's MovingPictures called XBMC(Local) wich was published on 23.07.2011 - more than 4 years ago and the data is still well imported, since every plugin on other projects, dedicated to import Kodis SQLite dbase get broke nearly on every version the Kodi devs are releasing dure to altered tables and variables and so on. Furthermore Emby Media Server seems to handle this nfo's but is at least generating nfo's using all the same tags, as i noticed on a first overlook. Conclusion: There are already 4 projects that supports this specific nfo' format ... and that is only what i know so far (but i will check all other topic relevant projects for that too in the future). I hope this ins't interfere with forum rules if i post a link into Kodis WIKI for an brief description into this spoiler: [SPOILER="Mod: please remove if interfere with forum rules."][URL]http://kodi.wiki/view/NFO_files/movies[/URL][/SPOILER] OK, but this class is already there? So this should not be that big deal anymore ;) And: I will not swear on it, but as far as i remember even Wordpress is using XML-Files sturctered in that way for importing/exporting new posts and even edits from external clients and i think for exchanging the pingbacks with other Blog/CMS/Forum-Systems too. Also this structure is used within Kodis movie nfo's for streaming-details (sort of media-info of the videofile) and in the tvshow.nfo too (which is placed into the series mainfolder and contains the infos about the series in general)... One thing to add may will be an additional scrape thetvdb for the season-related infos whilst import the nfo's of episodes from this season. Much more complex seems to be the handling of dynamic data in the nfo's... the only that comes to my mind here is the view-count... but this value should be synchronized between library and .nfo in an reliable way and should be waive external things like trakt and also be easy to setup (kodi needs an extra plugin as well as some system-settings and on top you need to edit a XML config-file manually to get this working, i think you guys on MePo could perform better on this issue easily :D ) ... Maybe parted movies (bla-a.avi, bla-b.avi or bla-CD1.avi, bla-CD2.avi, i.e. Kodi responds on -CDx and perform generate nfo onto file CD1 only and also span the parts at playback) will make extra work... or movie-collections/series/sets and things like that. But at all, it wcould be not that big problem in order to make use of these nfo-format I think we could ignore on this. It seems this was intended to have more flexibility in handing over goal-orientaed informations to the scraper, mainly this was implemented to easily make use of an completely different kind of files that wears the extension .nfo too i think. (Meaning those ascii-files which are mostly attached to video files released by <the-part-of-internet-we-dont-talking-about-in-here> and that are containing not many usefull informations, except an imdb-link or tt-number mostly ;) ). As you said, you drag and drop the folder you have extracted from some .rars onto your video-archive disk, letting kodi pick the imdb-link/tt-number to scrape with and after scraping you replayce this .nfo with kodis .nfo filled with the whole XML data ;) So we have at least 4 projects working with this standard, and to repeat that, that seems to be not changed since years in general terms. I also cann not see the problem, if there are projects using some own specific tags in addition to the universal used tags, since you not have to process on every tag and can skip unknown tags. Also it is free for any project to skip some universal tags in order to generate these information by itselfs, i.e. media-information or something like that. Important for the User are only the tags like title, sorting-title, plot, outlin and some more. On tags like actor or writer the number of user that is altering content here will be much more smaller already. Importing the nfo also dosen't say, that there should be none additional scraping tasks added to fulfill the needs of the project i.e. for fill up some specific art-work that is used, only to NOT leave content altered by the user untouched is an no-go. I cannot agree here, since structure of the nfo's looks like valid XML to me and is used by other serious applications that way too. It also reflects exactly the example that is shown on wikipedia at all (not that this is an measurement to me, i only say;) ). Dunno, but we are talkin about VS here, right? I am a bit out of practice. But at least i would be able to fire up free VS-MistressEdition and handle this like simplyfied noobish text "parsing" in the way of searching for the tags and cut the text between them, pushing this into vars in order to write this down to an dbase, if this would not be that totally Mr. Dumbiverse code of the year it would be then :D I can not get your point here, it all counts down on the major tags never to be changed. How this is implemented, processed, sourrounded by additional things and turning out in any project or not - all this is fully decided by an projects dev-crew on their own behalf. Only the tags have to be keeped the same. Seems like standard is already there and working fine. Why not simply using the power of 4 Projects (remember there are maybe already more) to coalesce on this as an exchange format? The only thing to do is fixing this existing standard tags to be sure it remains unchanged during the next years (unchanged means here: never alter an existing tag, only add new tags and let old tags simply dieying, so it is compatible downwards at any time without blocking new developments). But in the end i am sure, that this nfo's will work the next years if there is an coalition or not. This was only an additional improvment that i was suggesting with this. The Important thing is to make it possible, that at least MePo2, better also MePo1 can import these nfo's generally for the users that want to switch from another project to MePo or using multiple projects simultaneousely, that was my major point ;) But don't think my vision stops with the nfo's ... did you know that Kodi and the 3 other projects can im/export artwork in an format like videofilename-poster.jpg, videofilename-thumb.jpg etc. too? :D No no, dont be afraid, now i am done here this time ;) If any of the devs like further informations i can link to more infos as well as to nfo's with real sample-data for movies and tv shows, please PM me in that case ;) Thanks for discussion and your interrest, with all the very best regards. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
General
this view could not be built
Contact us
RSS
Top
Bottom
