[watzen]

3. when marking an item as watched in the fanart viewmode it doesn't perform the usual scroll animation to the next item in the list. It's more like it refreshes the whole view and jumps directly to the next item.

[jmarshall]

Regarding 1, is it just the issue with "can't find the item" on attempt to playback or are there other issues (eg info isn't shown for the items etc?) Check out the added columns (c21 in movies, c18 in episodes etc.) and check the paths listed there - that's the path to the directory item that represents the item to play (movie folder for instance).

Cheers,
Jonathan

[watzen]

The info that is displayed in the "Media Info" view is present, though I can not bring forth the information window by pressing "i".

c21 in movies is, I guess, production country, c22 on the other hand is the path to the file.
c18 in episode is however the full path to the file, but episodes still won't play.

the contents of a c18 row in episodes:
'smb://HTPC/TV-shows/Bones/Bones S06E01 720p WEB-DL DD5.1 H264-NFHD.mkv'

I set up a test db on my server for testing purposes. And then I built a new library using this build. And the resulting database is working but has the same column info in c22/c18 as the upgraded one. I guess the problem lies somewhere else.

the log says

02:51:10 T:4184 M:2480533504 WARNING: XFILE::CFileFactory::CreateLoader - Unsupported protocol(1/smb) in 1/smb://HTPC/Movies/

[jmarshall]

Ok - it'd be worth grabbing a Debug Log from you failing to start an episode/movie - just to see whether it's actually a db problem or is just something I haven't caught yet.

[jmarshall]

Okay, a bunch of fixes have been pushed. Basically all of the above except for those issues caused by the background loading of extra info (eg watched filtering won't work, items don't show immediately etc.)

I'll see if I can get things a little bit faster so that we can just grab the info from the database with the dir fetch.

Cheers,
Jonathan

[Jezz_X]

I would like to throw my 2 cents work in here on actual layout. What you have done here is great jmarshall but I think it would be nicer if it was implimented the same way as has been discussed in the other library threads.

Remove the actual files node and have the sources in the library root. And have the ability to add smart playlists too root to replace the current nodes (if needed)

[jmarshall]

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

[pecinko]

Hi guys,

On my github, you'll find a files_in_lib branch which removes the use of MyVideo.xml, replacing it with a Files node in the root of the

OK, I tested on my old win notebook with build Jezz_X sent. All settings were left on defaults and I added my sources (on NAS) using context menu as add videos didn't seam to work.

On NAS, each kid's movie have it's own separate folder with folder.jpg. IFAICT, folder.jpg and fanart.jpg are not being picked up as thumbs. I can't comment further on this as it is all I use in files mode.

It's nice that we are to get rid of library vs files dualism, though, If I should comment on way Files are going to be merged, I would have to say I don't like it much. I expected "Sources" item along with Genres, Titles, Directors... OTOH, you said it's the first step so maybe it will be completely different in the end.

[watzen]

ok, so here is a log from the following setup:
mysql server is on computer1
computer1 has created the database and populated it with a couple of movies. Using dharma build.
computer2 is running the build from before your most recent changes and after it has run, the database xbmc_video_test2 doesn't work with either the old or the new build.


http://pastebin.com/iAVCTQeP

[pecinko]

It's nice that we are to get rid of library vs files dualism, though, If I should comment on way Files are going to be merged, I would have to say I don't like it much. I expected "Sources" item along with Genres, Titles, Directors... OTOH, you said it's the first step so maybe it will be completely different in the end.

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://). In order for this to make sense, we would need MyMovieNav.xml (pointing to videodb://1/), MyTVShowsNav (videodb://2/) and MyMusicVideosNav.xml (videodb://3/). 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.

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).

This would also help navigation as it reduces nav steps by one. Current situation with most skins is home page to media jumping, making videodb:// and videodb://*/ use a little difficult and not quite obvious.

I would leave it to skinner's decision to choose if MucisVideos would be separate item in main nav or linked as Music subsection (it opens videodb://3/ in either case).

Just my 2 euro cents :-)

[Jeroen]

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?

. 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?

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.

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)

[pecinko]

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.

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..

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.

[topfs2]

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.

[jmarshall]

@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.

[jmarshall]

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