Removal of Files views - need skinner comments

pecinko Wrote:My thoughts regarding actual / planned layout from a skinning and usability point of view:

With files merged, I would consider discarding current video root view (videodb://)

How would I get to my playlists? Or video add-ons?

Quote:. In order for this to make sense, we would need MyMovieNav.xml (pointing to videodb://1/), MyTVShowsNav (videodb://2/) and MyMusicVideosNav.xml (videodb://3/).

How would be different from the current situation aside from separating code?

Quote:One can object that this is not simpler as I'm adding additional xmls but, from my experience, those 3 media types are different enough (especially TVShows poster/banner) so skinner needs to separate code for them even if using only one xml - (MyVideoNav.xml). IMO, this separation can make using of conditions easier (Container.Content() ) and reduce need of using custom xmls (ViewsVideoLibrary.xml) for code readability.

IMO this would not make it simpler, in fact it would result in more code in certain situations. Some pieces of code are used for more than one content type. Separating into multiple xmls would result in having to either duplicating that code or putting them in includes (in which you would be separating based upon content all over again)

The same goes for the viewtypes, some of them are used for multiple content types. I like to separate the code for the viewtypes and the actual xml for the library screen, and I think that more skinners use custom.xml's for that reason. So in your proposition I would still be using them.

Quote:Further, I would move recently added and playlists to each of those sections and add "Sources" and "Search". Sources (aka Files) opens list of added sources and "Search" brings up context sensitive search dialog based on section chosen (Movies, TVShows, MusicVids).

What about mixed content type playlists? Where would I look for those if playlists reside in separated nodes?

A search entry in general would be good, although I'm not sure if XBMC is capable of searching through multiple parts of the database though (so tvshows and movies at once I mean for example)

Jeroen Wrote:How would I get to my playlists? Or video add-ons?

They would be part of those separate nods. I don't know if there are any plans for Add-ons library, where they could be organized in subsections.

Quote:How would be different from the current situation aside from separating code?

From user point of view you would find everything you need in appropriate section. So no need for switching between videodb:// and videodb://*/ - easier and more user friendly.

From skinning point of view you could use the fact that code is content separated so you can ditch some of those Container.Content() stuff. So if I'm doing banner view I would put it in MyTVShowsNav.xml only. If I want to reuse list view, I would simply use includes. Easier to read and organize code. But, yes, you're right it wouldn't be that big of a change.

Finally, currently you need to provide links to library root, files, movies and tvshows. I know that you're doing this differently by using "proper" way (common videos link) but majority of skins does not do that or are providing an option to switch between videos vs movies/tv shows which only complicates things further..

Quote:What about mixed content type playlists? Where would I look for those if playlists reside in separated nodes?

I must admit I don't know what mixed playlists are. If it is about mixing TVShows and Movies in one playlists, I would list those in both sections so I could get to them either way.
- - -
Generally speaking, from my point of view, you should be either going to root ONLY and proceed further from there (e.g. no direct linking to Movies) or, you go to separate sections and find everything there. But, that's just mine opinion.

jmarshall Wrote:Yup - Plan is to first get the Files node in there (and files view out of the way).

Then the actual layout will be made configurable (probably just via XML - not sure if we'll try and UI it), allowing you to pop some of the sources in library root if you like. Similarly, the "Movies" and "TV Shows" overview nodes will also be configurable (and you'll be able to add other folders should you want them for smartplaylists and the like).

Sound good?

Cheers,
Jonathan

I think having a "sources" node would be really nice, then in the root of the library you can add some form of "Add Virtual Node" which essentially works exactly like creating a smart playlist. So you name the node and state what it should filter based on. We can always have a few preset ones (which is what movies et al is). Seems like you could extend that to be more flexible IMO, so if you want source A in root you create a virtual node which is based upon data from source A but filter nothing.

@watzen: it appears your db is screwed up indeed - notice the 0/smb stuff it's trying to have - where it is getting the "0/" from? This is just from a db upgrade, right? If so, I may have to grab mysql and debug it.

Regarding reorganisation, I see a couple of things:

1. If we assume that a source contains only one type of videos (eg only movies) then for sure it could be listed in the main "Movies" overview node. We could for instance have sources://movies/ to complement sources://video/, the former showing only those sources which have content set to "movies". The problem, ofcourse is that XBMC allows you to set content type on any folder, so it could well be a subfolder. Perhaps this could be discouraged (it certainly simplifies things), or we could have a content type "mixed" or some such.

2. The reorganisation will allow basically any structure - so smartplaylists and nodes could be placed relatively flexibly - the main "Overview" nodes would simply be folders that contain other nodes, so certainly the user could manually add some sources in there, but I think I'd prefer it to be automated if at all possible. eg I'm not sure if a listing of:

Titles
Genre
Actors
Directors
Sets
Files

is better, or:

Titles
Genre
Actors
Directors
Sets
Source1
Source2
Source3

The former is easy to specify as the "Files" node is auto-filled with all sources of type "Movies". The latter must either be specified manually, or we must have some sort of "combined listing" where we list both the "Files" node and the "overview" node (similar to a multipath.) Personally I prefer the first, with the latter allowed via manual config.

Cheers,
Jonathan

jmarshall Wrote:@watzen: it appears your db is screwed up indeed - notice the 0/smb stuff it's trying to have - where it is getting the "0/" from? This is just from a db upgrade, right? If so, I may have to grab mysql and debug it.

yup, only from a db upgrade. creating a new (mysql)db from these builds works perfectly.

jmarshall Wrote:Regarding reorganisation, I see a couple of things:

1. If we assume that a source contains only one type of videos (eg only movies) then for sure it could be listed in the main "Movies" overview node. We could for instance have sources://movies/ to complement sources://video/, the former showing only those sources which have content set to "movies". The problem, ofcourse is that XBMC allows you to set content type on any folder, so it could well be a subfolder. Perhaps this could be discouraged (it certainly simplifies things), or we could have a content type "mixed" or some such.

Personally I always like making stuff stricter with less special cases.

I think if we first take a step back and look at why the subfolder thing may have been needed and used we can see if its possible to omit it. What I believe is that a user in some shape or form uses the files view to navigate the media, if so it may make sense to set smb://foo/ as movies but smb://foo/bar as tv shows, because they have this weird structure on their NAS and do not wish to have both as seperate sources in their organization. Another use case may be that they add smb://foo but set content on smb://foo/movies and smb://foo/tvshows as they only want to show foo (the computer) in the file list, as it gives easier navigation.

Both of these cases are IMO just for organization and if we can have a better scheme for organization we can remove that sub folder stuff. IMO the sources node should be just a place where you specify sources for your library, with that definition the organization of this node does not matter as it shouldn't really be used to navigate the content. In that regard adding both of the sources in each of the cases above is an ok requirement IMO. As for the first case it seems to me that we could easily have the a root folders content setting take precedence over what it may be in recursive. Hope I am making some sense

jmarshall Wrote:2. The reorganisation will allow basically any structure - so smartplaylists and nodes could be placed relatively flexibly - the main "Overview" nodes would simply be folders that contain other nodes, so certainly the user could manually add some sources in there, but I think I'd prefer it to be automated if at all possible. eg I'm not sure if a listing of:

...

The former is easy to specify as the "Files" node is auto-filled with all sources of type "Movies". The latter must either be specified manually, or we must have some sort of "combined listing" where we list both the "Files" node and the "overview" node (similar to a multipath.) Personally I prefer the first, with the latter allowed via manual config.

Cheers,
Jonathan

I'm not really sure (could be because I haven't had my coffee yet) if you are talking about the root or what should be listed in the movies section? but I'd like the root of the library to be something like:
Movies (autogen)
TVShows (autogen)
Sources (here we add whatever we want in the other nodes, it is unorganized in the aspect of navigating media and just a way of getting data into the library).
VirtualNode1
VirtualNode2
...
VirtualNodeN

(Sorted in a natural way) All VirtualNodeX are stuff the user can specify via something similair to smart playlists.

Double "mark as watched/unwatched" in context menu for a root node:

@topfs2: Yup - we're on the same page. What I'm getting at is it would be useful to have "Movie" sources listed under the "Movie Overview" node (where you have Titles, Genre, Year etc. you'd append a "Files" node) So showing only sources which have content set to "movies" in this listing would be useful, should the user decide to do that.

The VirtualNode thingees are then a manual setup on behalf of the user.

Thus, by default everything would be exactly as it is now but with the addition that the "Movie Overview", "TVShow Overview" and "MusicVideo Overview" pages will also have a Files node added.

In the future, these will be editable (specified via XML).

@watzen: will take a look.

Cheers,
Jonathan

@All: I've made several updates (and rebased to master) that fixes a bunch of stuff, and also moves the information retrieval into the GetDirectory call, rather than having it backgrounded - it's still fast enough (almost as fast as retrieving the full movies node).

This means that watched filtering etc. is all working now (even if the source isn't in the library)

I've rebased on master, which means unfortunately the videodb version has been bumped again (as there was a version bump for mysql related issues the other day). Thus, if you have used my branch before, you'll need to drop your db and use a fresh one.

It would be great if you could test it out - I think it's just about ready for pushing this initial bit into master.

If someone could build for win32 (as I think that's what most use?) that'd be great - I'll see if I can hook one up tomorrow if noone else gets to it.

Cheers,
Jonathan