Kodi Community Forum
How many people only(or mostly) use file mode due to library limitations? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: How many people only(or mostly) use file mode due to library limitations? (/showthread.php?tid=124378)

Pages: 1 2 3 4 5


RE: How many people only(or mostly) use file mode due to library limitations? - DiMag - 2012-12-05

@jmarshall ---"if they [documentaries] 're not tvshows, why are they on thetvdb.com?"

Ned Scott provides a perfect answer: When XBMC says TvShows, it means videos with episodic content. Since most documentaries come in multi-part form, a tvshow.nfo is the best XBMC offers to accomodate them.

@jmarshall, Ned Scott:

Still, it is not good enough.

The problem lies, firstly, in a misconceived, from the point of view of the theory (science) of literature, implementation within XBMC (and other media managers, no doubt) of the notion of "genre". Documentaries are not genres in the sense that drama, comedy, thriller etc are genres of fictional works (movies, tvshows), but an altogether different type of work: non-fiction. Even if xsps can be used to successfully isolate documentaries from TV shows proper, the question remains why should they be mixed in the first place.

Secondly and more importantly, they cannot fix the problem that documentaries require different metadata information than movies or tvshows. In contrast to fictional works documentaries are subdivided by have fields and subject-matters not genres. Even if tags can be used to express subject-matter, the problem remains that they have been conceived as a super-set of sets to to collect together the same theme (say, infidelity) alongside different genres (drama, comedy, thriller), whereas each specific field of documentaries has its own exclusive subject-matters, and the relationship of subject-matter to filed is almost exclusively hierarchical.

To illustrate, consider a structure Documentaries/Economics/Economics of Regulation and Documentaries/Economics/Finance. You may use the tag "Problem of Agency" to collect together items alongside both folders, but how are you supposed to express the Documentaries/Economics/Economics of Regulation and Documentaries/Economics/Finance using tags? Clearly, you need an info file to define Economics as a category of Documentaries, and Theory of Regulation and Finance as fields of economics. Notice that these are no arbitrary divisions created by me. Once you recognize documentaries as a distinct video files type you are forced to implement a hierarchical categorization sub-structure. Incidentally, this would benefit movies too. There are by now too many sub-genres and genre hybrids crying for recognition within XBMC's schema, and as noted above tags are good only for collecting, not for subdividing.

Consider, furhter, historical documentaries. They often relate to a specific time period. (Even if is is 1,000 years long, such as the duration of the Roman Empire.) At present, the only time reference we get is their age of publication. How much sense does it make to switch to year view and find, bundled under "2012", a history of the Crusades together with a history of the Napoleonic Wars, only because they happen to have been published in 2012? What is clearly needed is a tag defining time periods, and a database infrastructure which understands notations as 1492-1648, 1688-1904, 1914-1945, and 1917-1989, and can collapse the shorter time period within the longer.

Perversely, file mode works best for documentaries, as it allows for hierarchical categorization using subfolders. Surely we all agree that library mode is there to do better than this.

Based on this reasoning, I submit that at present documentaries are treated by XBMC as library orphans. That neither tags nor smart playlists nor custom nodes can remedy this. And that if movie.nfo has been developed to provide proper metadate information for movies and tvshow.nfo for TV shows but neither suffices for documentaries, what is needed is the definition of documentaries as a new video files type with an appropriate for this type schema (tags).

I should perhaps add that I have given similar thought to the issue of handling of ballet, opera and theater performances, where I have come to the conclusion that the established movie.nfo suffices, provided for the addition of only two or three more (new) tags.


@artrafael:

I sincerely apologize for using expressions such as "perverse logic", "must be fixed", "why it is not used is a mystery to me". They are staple in my trade (law), and I got carried away. Again apologies.

Yet clothed in these impermissible expressions are some factual opinions which, I think, must be answered.


RE: How many people only(or mostly) use file mode due to library limitations? - HenryFord - 2012-12-05

(2012-12-05, 16:01)DiMag Wrote: The problem lies, firstly, in a misconceived, from the point of view of the theory (science) of literature, implementation within XBMC (and other media managers, no doubt) of the notion of "genre". Documentaries are not genres in the sense that drama, comedy, thriller etc are genres of fictional works (movies, tvshows), but an altogether different type of work: non-fiction. Even if xsps can be used to successfully isolate documentaries from TV shows proper, the question remains why should they be mixed in the first place.
Well - Documentaries are sporting genres as well. "Historical", "Science", etc. - aren't these applicable for Documentaries? XBMC really doesn't make any difference between non-fictional and fictional content, it's just like the way Ned Scott said: the differences are if something is coming up episodical or standalone. We just words for them which are applicable to most people: Movies (Standalone) and TV Shows (Episodical). But this applies to documentaries as well - there are documentaries which are releasing standalone (i.e. as "Movies") and there are some being released episodical (i.e. as "TV Shows").

Quote:Secondly and more importantly, they cannot fix the problem that documentaries require different metadata information than movies or tvshows. In contrast to fictional works documentaries are subdivided by have fields and subject-matters not genres.
This is rather subjective - Documentaries can as well be subdivided by their genres, as pointed out above. The point you are trying to make is that we should have a different order-algorythm for documentaries based on the subject-matters. I'd disagree though, it makes sense to me to subdivide them into genres as well - non-fictional genres are as valid as fiction genres.

Quote:To illustrate, consider a structure Documentaries/Economics/Economics of Regulation and Documentaries/Economics/Finance. You may use the tag "Problem of Agency" to collect together items alongside both folders, but how are you supposed to express the Documentaries/Economics/Economics of Regulation and Documentaries/Economics/Finance using tags? Clearly, you need an info file to define Economics as a category of Documentaries, and Theory of Regulation and Finance as fields of economics. Notice that these are no arbitrary divisions created by me. Once you recognize documentaries as a distinct video files type you are forced to implement a hierarchical categorization sub-structure. Incidentally, this would benefit movies too. There are by now too many sub-genres and genre hybrids crying for recognition within XBMC's schema, and as noted above tags are good only for collecting, not for subdividing.
That's what I don't get - if we'd have scrapers specifically for documentaries (and therefore backends to access which would provide such information) you could still deal with genres and subgenres - the upper genre is "Documentary" or "Non-Fictional", just to provide a basic starting off point, and then you have subgenres to that - like "Economics" which again would have a subgenre "Economics of Regulation and Documentaries", and so forth. This would fit into the current schema XBMC employs right now, this would just require (a) scraper(s) to do exactly that thing. I have to admit, I am unaware whether it is possible to have subgenres to subgenres in XBMC, but that would be the approach I would take. Of course - the "wording" might seem off, because you do not speak about "fields" pér sé but about "genres", but that's really not something that would matter, would it now?

Quote:Consider, furhter, historical documentaries. They often relate to a specific time period. (Even if is is 1,000 years long, such as the duration of the Roman Empire.) At present, the only time reference we get is their age of publication. How much sense does it make to switch to year view and find, bundled under "2012", a history of the Crusades together with a history of the Napoleonic Wars, only because they happen to have been published in 2012?
It does make sense indeed - because that's what we are doing here: We list them from the years of publication. That's how everything is working, and the "Years"-View is exactly that: A view sorted by the year of publication.
If you want to have it listed for the periods they portray rather than the publication-dates, genres could help you out once more - again, the wording might be wrong, but that shouldn't be a dealbreaker. You still could get your view as you want it: Simply by emplyoing a genre, say, "Historical" and then a subgenre "Era" or "Period of Time" witch again would employ subgenres of the different Eras or Periods. This again would simply need a scraper to do just that (and of course a backend to provide such information).

Quote:That there might be _another_ method to do this What is clearly needed is a tag defining time periods, and a database infrastructure which understands notations as 1492-1648, 1688-1904, 1914-1945, and 1917-1989, and can collapse the shorter time period within the longer.
It wouldn't even be necessary to design a new infrastructure for that, ot tags to do that. If there would exist a backend that would give the information as "genres", it would be enough. If a movie has the genres (it can have an undfined number of genres afterall) "Napoleon Bonaparte", "French Revolution" and "1789 - 1799", wouldn't that be enough? Now - you could then simply go ahead and define an own node for that, which again gives you the ability to look for a certain "genre" in a subset of movies.


RE: How many people only(or mostly) use file mode due to library limitations? - Ned Scott - 2012-12-05

It's currently a technical limitation and has nothing to do with how we view the content. Believe me, if we could easily mix the two without any kind of visual/skin hacks, we would. Until then, people can always view library data in a directory structure in the files view, which will allow you to have metadata, but isn't as dynamic as some of the other options.


RE: How many people only(or mostly) use file mode due to library limitations? - DiMag - 2012-12-06

1. - XBMC LIBRARY'S LIMITATIONS
@ned Scott:

If XBMC's treating of documentaries (and other video content) as library orphans "...is currently a technical limitation and has nothing to do with how we view the content.. Until then, people can always view library data in a directory structure in the files view...", we must indeed leave it at that.

Still I am curious what exactly the source of the said limitation is. Is it the database engine? Or is it the desktop?

(Concrete question: Say I define a custom tag in an nfo file, one not provided for by movie.nfo or tvshow.nfo. How can I map it to a database table? And if I do map it successfully, can I define a custom node to display the relevant metadata, or are custom nodes restricted to existing database entries?)

2. - DO WE NEED A NEW VIDEO FILES TYPE CALLED DOCUMENTARY?

The answer of the developers seems to be "we need just two data types, one to describe episodic content and one to describe unitary content, but we should not introduce data types based on content alone". Mine is a different approach: "We need a new data type each time the need emerges for addition to an established data type of so many new, or subtraction or modification of so many already existing, tags, that the patching would become unwieldy."

On this basis I submit that:

Documentaries meet the test: Entirely different data type: nonfiction | drop genre, add subject-matter, field/sub-field | for historical documents, add time period/region reference | drop actors, add persons concerned.

Ballet, opera and theater performances don't: suffices to add three new tags to movie.nfo while subtracting nothing from it.

I have not really thought about other media types, though I would say that lectures and newsreels should be considered documentaries, and sport may, prima facie, be a category of its own ---but a documentary it isn't.

3. - THE LACK OF SCRAPERS ARGUMENT

A recurring argument against introduction of a new media type is "not until there are scrapers for it". Although I am as frustrated by the lack of scrapers as anyone else, I do not accept this argument for two reasons:

(a) Firstly, I believe it puts the oxen before the cart. No web site will make metadata available unless it has an established schema against which to map them. It is rather to be expected that XBMC's adoption of a new data type schema shall offer inducement for providing the metadata to fit into it.

(b) Secondly and perhaps more importantly, there may be scrapable metadata out there you simply are not aware of. To offer an example, I had long lamented the lack of scrapable metadata for ballet and opera only to discover that the Lovefilm (movie) scraper offers a surprising amount of such data. You may not find all performances, but you shall surely not miss the big and recent ones. How did I find out? By trial and error; Lovefilm does not advertise the fact.

Then there is Wikipedia. There is in the whole web no more organized, reliable, and beautifully written source for any material, from sniper rifles to contemporary art. Even if Wikipedia is not scrapable (incidentally: why is it so?), you may visit it, download the page in html, cut and paste what you need in <plot> (or a more appropriate tag of the new media type to be), and enjoy a media info view that actually informs.

4. - LEAVING XBMC AS IS: GENRES AND SUB-GENRES AS CATEGORIZATION TOOLS

"Genre" is an occupied term, developed over ages, indeed centuries, by the science of literature, whence it has been ported to films (movies). It is a term, and a methodology, well developed --and ever evolving-- in science and well observed ---indeed cherished---by the movie industry. XBMC's implementation of genres per the <genre> tag raises issues.

(a) Firstly, it is incomplete as it does not provide for a second-level categorization into sub-genres. And this hurts, because as soon as you distinguish between different genres (and styles, which are sometimes distinguished from them, other times mixed with them; the film-noir, e.g., is technically a style not a genre), you are forced into a further distinction one level deeper into sub-genres. For example though they be both thriller, a psychological thriller is a completely different viewer experience than a crime thriller. A good media library must be able to express this hierarchical relationship visually: it must show psychological thrillers as a distinct category, but also as branches of the thriller trunk.

Ned Scott would seem to argue that XBMC cannot handle sub-genres, and this is a built-in limitation which cannot for the time being be addressed. But is XBMC really thus limited? What puzzles me is that the same XBMC that cannot handle sub-genres with respect to movies and TV shows can handle a similar hierarchical relationship in the case of music, where the tag <format> is used to further subdivide music genres into what is essentially a sub-genre. Are sub-genres really out of present XBMC's capabilities?

(b) Secondly, XBMC's laudable decision to allow for limitless customization of the <genre> tag has introduced a source of confusion, inasmuch as everybody trying to subdivide movie and Tv shows one level deeper than currently allowed by XBMC is moved to baptize his categorization "genre" even if it is nothing of the sort. My thesis is that terms which have acquired a meaning as a result of centuries of scientific elaboration should be respected for what they stand for, and that any disrespect breeds unwanted confusion with unexpected side effects.

To illustrate the confusion look no further than Henry Ford's contribution to this thread, where he suggests that what I propose as a time period filter for historical documentaries be implemented as a further genre of documentaries. He doesn't seem to realize that what I ask for is a date-time conscious algorithm able to fold the Battle of Jena (1806) and the Naval Battle of Watterloo (1805) inside the time period of the Napoleonic Wars (1803-1815), and further include within this period, as long as I decide to declare it a video node, anything art, literature or science related which occurred within the same time frame. Something similar, though on a cruder scale, is done within movies per the <year> tag. Surely a new <genre>1805</genre> would be no good substitute for an entry <year>1805</year>: genre does not know mathematics, and it helps when typing in "1805" not to have to scan your nfos for time periods (such as 1803-1815) including this year.


RE: How many people only(or mostly) use file mode due to library limitations? - HenryFord - 2012-12-06

(2012-12-06, 14:28)DiMag Wrote: The answer of the developers seems to be "we need just two data types, one to describe episodic content and one to describe unitary content, but we should not introduce data types based on content alone". Mine is a different approach
In the end, this all yields the same results:
Not enough users asking for it, not enough developers care for it...
Sorry, to say it so blatantly, but this is the main reason why it won't get any recognition beyond this point of the discussion. You can argue all you want - if the devs truly don't care about it (this is not, in any way, meant to be offensive to the developers) and users don't really seem to care either (this thread is not exactly filled with people who share you pov), you're stuck at doing it yourself. You may offer valid suggestions, but if there aren't that much people to care about such issues, you'll have to live within the limits which are already set. Implementing new datatypes just for a handfull of people seems to be a whole lot of effort.

Quote:(incidentally: why is it so?)
It's totally scrapable, there just isn't a scraper. And Wikipedia might have a problem with us excessively accessing their site for scraping purposes.

Quote:To illustrate the confusion look no further than Henry Ford's contribution to this thread,
You can speak directly to me, can't you?
I'm out of here then - you are asking for things that noone else is asking for, you are asking in a manner that is totally unusual for this forum, even for a discussion. You ask in "high words" (really, don't know that much english to be aware of another term for this), speaking about persons in third-person instead of adressing them directly (in this case: me) - this makes you look like you are speaking from a high horse and really - you can clearly see that neither the developers nor the users are willing to put up with this kind of discussion. You are speaking to persons here, people who put a lot of time into this project and try to help people out - not writing essays about issues that concern you. You are arguing and arguing, but yet - not contribution beyond that point.

I valid your input as a suggestion, but you should at least TRY to help with improvising and accepting cutbacks to your idea, yet you stand on your standpoint and dare anyone to offer different approaches.

Edit:
Removed a lot of stuff, because you are obviously unwilling to take any kind of suggestions yourself.
What you do is basically telling, not discussing.


RE: How many people only(or mostly) use file mode due to library limitations? - Ned Scott - 2012-12-06

DiMag, there's a lot of stuff that is always on the "to do list". We are taking steps forward to making XBMC break free from the traditional view of just "movies" and "TV shows". This is something that will improve in time, but it does take time. You're trying to argue for something that I don't think anyone opposes. The only thing I dare try to argue back is that it's not as hopeless or lost as you make it sound, and that there are at least some reasonable options in the meantime.


RE: How many people only(or mostly) use file mode due to library limitations? - DiMag - 2012-12-09

We are in total agreement.

In the meantime the question poses itself whether this discussion should be moved to a more general or better organized thread. As you point out I have made quite a noise about documentaries ---but maybe sub-genres are a more pressing matter. All these issues must be brought together under a more general heading.


RE: How many people only(or mostly) use file mode due to library limitations? - FIBO - 2013-01-20

Well,

As the "other tread" was closed: http://forum.xbmc.org/showthread.php?tid=33710&page=13 I'm giving this thread a small kick.

Reading and questioning through the forum and a few threads I'm not quite sure I do have an answer yet.

Making it clear again:

In the main menu there are two options for movie-type content: movies and TV-shows.

In all the answers given/read the suggestion is mostly to make playlists or "possible in the next (Frodo) release" selections however are made based on tags, but I would like to be able to make different libraries based on location. As I have a server with different drives and files for differend contend like kidsmovies dutch, kidsmovies english , kids-series, movies, series, animations ect.

I do like the Confluence structure with the main menu-bar. Now it only shows movies and TV-shows. The kids series or movies are played with MPC directly from the file. Because I don't want the kids-stuff mixed (library-wise) with mine.

So the clearest question to ask is if it will be possible (maybe in Frodo) to add selfchosen library-(names) to the main manu-bar. With content based on location and not on tags........


RE: How many people only(or mostly) use file mode due to library limitations? - Ned Scott - 2013-01-20

Unfortunately it's not a feature in Confluence, but it is a feature in several other skins. I'm also keeping an eye out for an actively maintained Confluence modded skin for people who want that look but with custom home items (there used to be some, but they're not longer maintained).


RE: How many people only(or mostly) use file mode due to library limitations? - jjd-uk - 2013-01-20

(2013-01-20, 19:04)Ned Scott Wrote: Unfortunately it's not a feature in Confluence, but it is a feature in several other skins. I'm also keeping an eye out for an actively maintained Confluence modded skin for people who want that look but with custom home items (there used to be some, but they're not longer maintained).
I think the Hybrid skin is the only option at the moment if you want the Confluence look but with the custom options.




RE: How many people only(or mostly) use file mode due to library limitations? - FIBO - 2013-01-20

(2013-01-20, 19:19)jjd-uk Wrote:
(2013-01-20, 19:04)Ned Scott Wrote: Unfortunately it's not a feature in Confluence, but it is a feature in several other skins. I'm also keeping an eye out for an actively maintained Confluence modded skin for people who want that look but with custom home items (there used to be some, but they're not longer maintained).
I think the Hybrid skin is the only option at the moment if you want the Confluence look but with the custom options.
Thaks, but....
Googeling Hybrid Skin XBMC doen't give any results. Via the Add-on - skin, I can't find anything called like that eighter. May I ask to point me in a right direction?

@ Ned Scott
Do I draw the right conclusion from your answer that it won't be a feature in Frodo? I'm not bound to the Confluence skin. If another skin gives me this option, I like to try it out. From the pictures I see from other skins I never saw a menu extended like I'm looking for. could you be more specific in "several other skins"?


RE: How many people only(or mostly) use file mode due to library limitations? - jjd-uk - 2013-01-20

(2013-01-20, 20:15)FIBO Wrote:
(2013-01-20, 19:19)jjd-uk Wrote:
(2013-01-20, 19:04)Ned Scott Wrote: Unfortunately it's not a feature in Confluence, but it is a feature in several other skins. I'm also keeping an eye out for an actively maintained Confluence modded skin for people who want that look but with custom home items (there used to be some, but they're not longer maintained).
I think the Hybrid skin is the only option at the moment if you want the Confluence look but with the custom options.
Thaks, but....
Googeling Hybrid Skin XBMC doen't give any results. Via the Add-on - skin, I can't find anything called like that eighter. May I ask to point me in a right direction?
Go to http://forum.xbmc.org/forumdisplay.php?fid=177

I've not kept up with the latest developments so not sure how stable it is now as it's a relatively new skin, perhaps the author is not confident on the stability enough to push it to the official repository yet.. I'd suggest reading the posts on that forum to see how things are proceeding.




RE: How many people only(or mostly) use file mode due to library limitations? - FIBO - 2013-01-20

I'll do
thanx a lot.


RE: How many people only(or mostly) use file mode due to library limitations? - Mudislander - 2013-01-20

Hybrid is a Frodo Only skin & in the Official Addon Repo - and is very new :d


RE: How many people only(or mostly) use file mode due to library limitations? - jjd-uk - 2013-01-20

Btw, are you looking for the skin from a Frodo build? as it's a Frodo only skni, I've just looked and it's in the official repository so should definitely be relatively stable now.

All addons from in official repository can also be downloaded from http://mirrors.xbmc.org/addons/frodo/ with Hybrid at http://mirrors.xbmc.org/addons/frodo/skin.hybrid/ but it should definitely be listed within XBMC.