[DiMag]

In both Movies and TVshows video nodes, among the top level defaults there are "Year" and "Actors", and "Rating" is bsengt. I have issues herewith.

Years
Years is, as a video node, IMO completely useless. For when it opens, you don't have a list of your videos listed chronologically, with the year of release preceding the title --- a view which is extremely useful but, curiously, currently available only in the Ttile view node, using the option to filter titles in descending or ascending chronological order ---, but, rather, a list of all years for which there is a film entry. So you have an entry "1942". How on earth are you supposed to remember that this is Casablanca's year? What can possibly be the information value conveyed to you by "1942"? I submit none. ATTENTION, I do not say that cataloguing movies by reference to their year of release is a bad idea. It is indispensable; what makes no sense is providing a list of all years for which there is a movie entry.

Actors
Actors is useless due to circumstances: There are so many of them that the screen becomes unmanageably long, and it is unlikely that the ones you are truly looking for (say Marlene Dietrich, Humphrey Bogart, Laureen Bacall) shall be alphabetically top of the list. Clearly, what you need is a more selective filtering. And in that sense, <actor> is a great tag to use in smart playlists; as a video node, however, Actors makes no sense. What would make sense would be a video node Stars, which would mirror the special tag in MOVIE.NFO (though not in TVSHOW.NFO --- I never understood the reason of the omission) which specifically filters out the main role actors, or the top actors. Stars would produce a more manageable, hence truly useful, list. And it would be what users are after.

Rating
While rating it is not absent from the default nodes, it is not as visible as it should be: it appears only in Title view, and then only after applying <rating> as a filter. I think this does not reflect the importance rating has for users as a filtering option.

For all these reasons, I propose to modify the default video view nodes as follows:

• Either drop the Year node altogether, or substitute for it a chronological list of titles preceded by the year of release.
  
• Substitute Stars (<stars>) for Actors (<actor>).
  
• Add Rating as a same-level filtering node as Title, Genre, Year (modified), Stars, Tags, etc.
  

I can anticipate many developers' reaction to this proposal: "Come on, post Frodo this is all easily done per customization of the video nodes". And so it is. The question is, why should this be an excuse for shipping XBMC with two default video nodes which are clearly useless, and a truly useful video node hidden one level deeper, and I have not counted how many clicks further than it should be?

[jmarshall]

Sort by Year is completely different to categorising by year.
You can always SHIFT-type in any view to get to what you want, or alternatively use the filter on the left.
Rating is more a sorting option, no? How would you group them otherwise? 0-1, 1-2, 2-3 ? This has the same issue as you have with years, no?

[DiMag]

I do not completely understand what you mean by the first part of your point (sort by year etc).

As for the second part, you make a valid point, up to a point. It is my view that a system which ranks films on a scale of 0 to 10, or for that matter on a %-point scale, is, though useful in many respects, completely useless as a way of filtering a large collection of films. What you need is a more rough metric.

I use the following scheme:

• 5 stars for films which either (a) I like so much that I cannot stop seeing (even if I have seen them several times), or (b) which are universally acknowledged to be masterpieces, and thus I know I should see them again. Lawrence of Arabia is a 5 stars on both counts, Death in Venice only on count (b) --- but still a 5 star film.
  
  
• 4 stars for very good, and 3.5 stars for good films. Unforgiven would be a 4 star example. (I make no great effort in distinguishing sharply between 4 and 3.5 star films, because I know that in this rating bracket my appreciation may change over time.)
  
  
• 3 stars for films that I have not regretted watching.
  
  
• 2 stars for films that are just good for killing time, say waiting at the dentist's.
  
  
• Anything below 2 stars, I delete from disk.
  
  
• After some time, the 2 star films are deleted too --- to make room for new films.
  
  

When employing so rough a metric, it matters not that when opening the Rating node you don't get a list of all films preceded by their rating. What you need is a list of all films worth seeing tonight, depending on your current mood.

[jmarshall]

So when you click on "Rating", what do you see? Do you see 6 items (0 - 5 stars) ? Or do you see your titles, sorted by rating (descending I presume)?

[DiMag]

Items.

[jmarshall]

So it's the Titles node sorted by Rating.

[DiMag]

No, no. I see items (five, in my case), whose function is to filter movies in accordance with my rating system. Only after I open each one of them, do I see movie titles, including other information (such as release year) made available by the particular skin.

In case you asked this question because you are in the process of designing an optimal view mode, let me contribute the following.

The first visible node (currently Title) should act more like a universal node to collect all minimum optimal information. Which, I submit, should include:---

• Title followed by (Year). If useful, supplemented by original title.
  
• On the same or next line (a matter of ergonomics): Director, Stars.
  
• If adaptation, on the next line: The novel or play from which t has been adapted. (The current schema does not provide for this sort of information except as a cryptic inclusion in <credits>. IMO this is an omission to be corrected.)
  
• On a third line: Genre(s) and Rating.
  
  

EXAMPLE from my collection:

• Il Gatopardo (1963) | Lucchino Visconti | Burt Lancaster, Alain Delon, Claudia Cardinale
  
• Adapted from: Giuseppe Tomasi di Lampedusa, Il Gatopardo (Novel, 1958)
  
• Epic | 5 STARS
  
• (NOTE: On a different thread I argue that the current schema which limits rating information to just one source is inadequate, especially considering that the scrapers --- in particular, the Universal Scraper --- can fetch rating information from two of the universally acclaimed rating sites, namely Rotten Tomatoes and Metacritic. Thus a perfect third line would be GENRE(S) | USER'S PERSONAL RATING (if applies) | RT RATING | METACRITIC RATING.)
  
  

The GlassNox skin currently offers a view like the one I am describing (proposing) --- though it does not include information about director and stars or source of adapted work, and its rating information is, naturally, restricted to what is currently available in the NFO schema (and the database tables).

Once you have a view like this, you would like to be able to rearrange it (re-sort the filtering criteria) just at the push of a button, that is without having to invoke the side panel. Title, year of release, and rating would presumably be criteria everybody would like to make it to act as quick filters/re-filters.

Does having this view make the Rating, Directors and Stars views I proposed redundant? I think not. It makes them less essential --- but still useful.

So I propose to redesign the default view nodes as an Extended Title + Info node, followed by Rating, Director, Stars, Sets, Tags. And then, users' customized filter lists. Perhaps XBMC could be so kind to include a sample XSP, say a list filtering a director everybody loves, like Woody Allen.

[Montellese]

I think your requests are very much you-centric. I, for one, don't give a damn about directors or ratings from some website (either I like the movie or I don't, either way it has nothing to do with what other people think) and I also don't care about a lot of the other information available (which is why I usually choose a minimalistic view with title + poster + fanart + codec info). Furthermore it is always skin-specific how the available information is displayed. We don't want to enforce anything on skinners, they should be able to show the things they want in whatever way they want.

I agree that the Year list is probably not used often because it's not very informative. And the actors list takes far too long to load and a "Relevance" sorting option might be useful as well (i.e. show the item at the top which has the most references/appearances).

PS: You can create a custom keymap to map the advanced filtering dialog to whatever button you like using the "Filter" action.

[DiMag]

@Montelese:

I think your requests are very much you-centric. I, for one, don't give a damn about directors or ratings from some website (either I like the movie or I don't, either way it has nothing to do with what other people think)

It is impossible for a human to like or not like something irrespective of the attitudes of other humans. You may like to believe you are autonomous in that regard, but this is at best a self-flattery, at worst a self-delusion. Even worse, if you have indeed achieved that state, your likely return address is a lunatic asylum.

We don't want to enforce anything on skinners, they should be able to show the things they want in whatever way they want.

This is an argument often made by developers, and it is of course valid. Nevertheless, I think most users feel that the XBMC team should strive to make good practice recommendations, even if they are implicit.

I agree that the Year list is probably not used often because it's not very informative.

Why don't you spell it out? It is useless. Drop it, or modify it. Drop it would be easier.

And the actors list takes far too long to load and a "Relevance" sorting option might be useful as well (i.e. show the item at the top which has the most references/appearances).

Your mind is a developer's mind, and thus you have picked up something ("Relevance" filter) which I did not even suspect existed. When I recommended not droping the idea of an actor-based filter but, rather, substituting stars for actors, it was because this is by far the easiest solution. "Stars" offers a natural filter of top actors (mind you, it includes top actors even if they play minor roles), and, moreover, is provided by all metadata sites, and is already a tag in the NFO schema and a field in the database schema. Indeed the more you think about it, the more you are likely to question the initial choice of an actors filter instead of a stars filter.

PS: You can create a custom keymap to map the advanced filtering dialog to whatever button you like using the "Filter" action.

Thanks for the tip, I wasn't aware. It is so useful that I think should belong to the wiki.

[jmarshall]

We have no information on "stars" currently - the best we can do is something like the number of movies/shows/episodes they're linked to in the local database.

I believe it's only recently that IMDb has offered the cast in "credits order" and even then that's not necessarily any indication of stars. You have to get information from the actors pages to really determine that. Themoviedb's is possibly a better order. While that would be nice to have, we currently don't have it, so a lot more work would need to be done before the "stars" mode is possible via that technique.

Still, the "stars" idea would be reasonable enough within the local database. The trick would be what designates a star - i.e. how many movies do they have to be in before we don't bother showing them? What about tvshows? You could do some experimentation with this yourself by doing some queries on your database. Come up with a reasonable heuristic and I'm sure someone will take the effort to implement it, given that it can't yet be done generically via the filter system.

Cheers,
Jonathan

[DiMag]

@jmarshall:
Your comments go always to the heart of the matter --- but then you are XBMC's database guru, aren't you?

When I suggested substituting stars for actors, I assumed this would a trivial thing. I did that because I observed the tag <stars> in every NFO file I scraped (using, mostly, the Media Companion offline scraper, which uses for movies IMDB). Naturally, I assumed there was a corresponding entry in the database schema. But there isn't, as you point out. As you also point out, structuring this relationship isn't a trivial task.

f the task isn't trivial, the question arises whether it should be prioritized over other, similarly non-trivial but perhaps more pressing tasks. And here I got my second thoughts: how useful is a Stars node, really?

Suppose you are not interested in establishing statistically how often this or that actor pops up inside your movie collection, but rather you are interested in filtering your movie preferences on a "stars" basis. Say you like films starrig Humphrey Bogart, you like those where his partner was Laureen Bacall more than those where she was Katharine Hepburn, and you like dark films --- the American films later baptized "la série noire" in France --- better than romantic ones, and films which blend the dark with the romantic the most. As you by now realize, I have been describing a particular film, "To Have or Have Not"; but not, as it happens, "Casablanca" --- and you may actually like "Casablanca" more than you like "To Have or Have Not".

What I am trying to demonstrate is that at the end of the day, you may realize that Stars may after all be not terribly more helpful in filtering your collection than Actors; it is really useful only when paired with other criteria. And that what you really need is sit down, make up your mind about what you like and how much you like it, and write an XSP with the corresponding filtering rules. If Stars was already in the database, it would possibly --- but by no means probably --- help more in compiling this XSP than currently does Actors. But given that a lot of energy must go into setting up Stars, it seems more intelligent to direct this energy toward the end product, the XSP.

For all those reasons, I maintain my suggestion to drop Actors as not particularly useful (it is useful per se, but then the extreme length of the list makes it relatively useless), but withdraw the suggestion to substitute Stars for it.

I also understand that you and Montellese shall keep thinking about a clever way to limit the length of lists of useful filters turned useless because of size of results. Actors may not be the only field where this problem occurs.

[DiMag]

We have no information on "stars" currently - the best we can do is something like the number of movies/shows/episodes they're linked to in the local database.
.......

Still, the "stars" idea would be reasonable enough within the local database. The trick would be what designates a star - i.e. how many movies do they have to be in before we don't bother showing them? What about tvshows? You could do some experimentation with this yourself by doing some queries on your database. Come up with a reasonable heuristic and I'm sure someone will take the effort to implement it, given that it can't yet be done generically via the filter system.

What makes an actor a star? Let the producers speak out their mind/choices.

Every work has two or more lead actors/actresses. Not many more than four, as their inflated egos would be impossible to manage directorially. It then has roughly the same amount of secondary actors/actresses. (Secondary roles are optional, not essential. You can have a work with just lead roles, but you cannot have a work without roles. Even in a documentary about lions there are at least two star lions.) The total amount of lead/secondary actors/actresses is thus a minimum of two, an optimum of four, and an optional of anything between four and the number of actors at which managing their egos becomes directorially impossible. You don't have to guess these data. They are clearly stated by the producer: lead actors, secondary actors, all fixed in black on white in the credits.

Do information providers collect these data in a scrapable format? Probably yes. Wikipedia does, at any rate.

Is the filtering of stars out of actors something which should be on Team Kodi's mind? Clearly no.

I have read somewhere in this forum a statement from a Team Kodi member that default nodes, genres, tags, you name it are generally useless: "We just offer you the data to customize everything in smart playlists (and/or library nodes) matching your preferences & prejudices." (Paraphrased to let the core of the statement stand out.) The only things the defaults are expected to do is offer a lot of in themselves not very useful data from which you can collect the data set matching your preferences & prejudices. Of course, the reverse implication of the statement is also true: if left untouched, the defaults are useless.

In that sense, and in conclusion to this thread I opened, I retract my original feature request. Not because it is a bad idea, but because it is not up to Team Kodi to implement it.