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: 1165214" data-attributes="member: 68500"><p>Nice discussion tough <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>For all the developers:</p><p></p><p>I wan't to add this suggestion, even if it slides a bit offtopic here right now: The ability to read from AND on-demand generating into .nfo files on a per-videofile base (i.e. videofilename.mkv -> videofilename.nfo on same physical location) should be generally included. ALWAYS. And into all software that handles media. Relevant software is supporting this already: MePo1's Moving-Picture (scraper: read from local nfo in addition with external nfo-export plugin), XBMC/Kodi where this "standard" seems to come from, Ember-Media, UniversalMediaServer (ex PlaystationMediaServer) is currently working on this... to name some major ones.</p><p></p><p>Because this is not only an transparent and the only fail-safe way to backup the scraped data (which in most cases was needed to be manually matched by the user for relevant amounts of items or is manually altered in detail for several reasons), even if the active used dbase of the software fails completely without having backup handy or the user is accidentially over-scraping items with wrong data into the active used dbase, and after all, making it easy to re-import the correct data from the inactive nfo-files in such cases or simply when moving numerous videofiles to different locations etc. too (i.e. instead manually alter the location of any single item -> clear the database from unavailable items and then import data from nfos at new location).</p><p></p><p>It is also sort of an easy to use universal exchange format for video-metadata, to hassle-free moving media-librarys between different software or even to use it by several tools at the same time, no matter if SQLite, MySQL or whatever is used by an specific project and no matter how often the developers alters table-structures within those active dbases or other things in the softwares at all, what makes it necessary to rewrite all the dbase-importers on all the other projects etc. <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>It seems that it is not necessary to take care about all the tags possibly used by any and all other projects in those .nfo-xml files, but the basic ones (i.e. title, sorting title, collection, imdb-id, description, watch-count or any other one which makes sense or the users often likes to intentionally altering manually) should at least be supoorted.</p><p></p><p>To go further: I think, all the developers of media handling tools should work together more closely in order to develop this as "industrial standard" for backup and exchange the metadata <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>Just my 2 cents.</p><p></p><p>Feel free to move this to the whish-list or whatever <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 reading and best regards.</p></blockquote><p></p>
[QUOTE="resa, post: 1165214, member: 68500"] Nice discussion tough ;) For all the developers: I wan't to add this suggestion, even if it slides a bit offtopic here right now: The ability to read from AND on-demand generating into .nfo files on a per-videofile base (i.e. videofilename.mkv -> videofilename.nfo on same physical location) should be generally included. ALWAYS. And into all software that handles media. Relevant software is supporting this already: MePo1's Moving-Picture (scraper: read from local nfo in addition with external nfo-export plugin), XBMC/Kodi where this "standard" seems to come from, Ember-Media, UniversalMediaServer (ex PlaystationMediaServer) is currently working on this... to name some major ones. Because this is not only an transparent and the only fail-safe way to backup the scraped data (which in most cases was needed to be manually matched by the user for relevant amounts of items or is manually altered in detail for several reasons), even if the active used dbase of the software fails completely without having backup handy or the user is accidentially over-scraping items with wrong data into the active used dbase, and after all, making it easy to re-import the correct data from the inactive nfo-files in such cases or simply when moving numerous videofiles to different locations etc. too (i.e. instead manually alter the location of any single item -> clear the database from unavailable items and then import data from nfos at new location). It is also sort of an easy to use universal exchange format for video-metadata, to hassle-free moving media-librarys between different software or even to use it by several tools at the same time, no matter if SQLite, MySQL or whatever is used by an specific project and no matter how often the developers alters table-structures within those active dbases or other things in the softwares at all, what makes it necessary to rewrite all the dbase-importers on all the other projects etc. ;) It seems that it is not necessary to take care about all the tags possibly used by any and all other projects in those .nfo-xml files, but the basic ones (i.e. title, sorting title, collection, imdb-id, description, watch-count or any other one which makes sense or the users often likes to intentionally altering manually) should at least be supoorted. To go further: I think, all the developers of media handling tools should work together more closely in order to develop this as "industrial standard" for backup and exchange the metadata ;) Just my 2 cents. Feel free to move this to the whish-list or whatever ;) Thanks for reading and best regards. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
General
this view could not be built
Contact us
RSS
Top
Bottom
