[Jezz_X]

I would just like to point out here you know that big delay you get when entering a really large directory full of music that hasn't been scanned to the library.
Well thats the extra time it takes to read all the id3 tags from the music files before it can display them. if you turn off id3 reading its pretty much instant.

the same thing will happen if you have to read a bunch of NFO files for every movie in the list before you can see it. You say your fanart shows instantly (which I doubt anyway on an xbox) yes because it only loads 1 at a time. If you want to show the meta data int he list you would need to load it for every single file in the directory every time you enter it.

A better idea instead of letting it use the NFO files all the time is to actually use the library database file and fetch the info out of it (after you have scanned them in). But you say "getting info from IMDB takes ages" well since you allready have made all your NFO files anyway it will be no different on first scan than entering a dir full of NFO's but will be 100 times quicker on every other time you access it

[Kris_Toff]

I appreciate everyone wanting me to use the library mode and I think I explained why I don't want to.

The alternative I could consider is going into each of the nfo file and reset the genre to my taste.

Now in terms of performance, I can garantee you that I don't have 500+ movies in one folder, the biggest one is probably 40 so I wouldn't worry about this. If it can read 20 songs ID tags (btw from binary files, not well structured xml files) then it should read instantly 50 nfo files.
Even if it takes a few seconds per folder, the benefits of having this option as a nice skin would be tremendous...

BTW, if I use library mode and open the Action genre, it takes more than 10s and then I have to scroll through about 100 movies. In my Action folder, I have only 38 (other could be considered action are in adventure, war, sci-fi, etc...)

I would really love to be able to contribute to the programming xbmc team but it would take me way to long to get in it compared to one of you experts for which it would take probably 30mn...

If it can be a toggle video option in Settings/Video/Files/ then it could be up to the user to choose.

Pleeeaaaaaaaaaassssseeeee?

[jmarshall]

The way I see the future is this:

1. One view for all videos/movies/files.

2. Options to view by filesystem or by genre/category/whatever.

3. All db info is fetched in each case.

Exactly how this is presented to the user in terms of heirachy I'm not sure. Ideally it'd be customisable, but this might be tricky to do well from a 10 foot UI. I suspect an XML file or similar would be the first point of call as far as customising the heirachy that is shown.

EDIT: And obviously nothing is going to happen until after Atlantis (read: November may be the point where something is started, and I expect it will take quite some time to get right.)

Cheers,
Jonathan

[Jezz_X]

I didn't say (this time) to use library mode I simply said things would be a lot faster using the DB from library mode to get the tags.

As for the other of only having 50 movies in a dir sure that may be fine for you but we have to take into account everybody when adding these sort of things I personally have over 100 movies in a single dir and I'm sure many others would have over 500 or more. And I'm sure they would bitch at us to no end that their XBMC just got twice as slow at reading directories.

P.S telling the programmers its easy and will only take a few seconds hurts your position not helps it. Just check out the <rant> bit in this post from jmarshall http://forum.xbmc.org/showpost.php?p=174...stcount=11

[BritneysPAIRS]

I would say it only needs to load it if listitem.rating etc was called, so it would freeze a little on lookup like fanart does (but if set to only appear with 2 secs of no keypress like aeon) would be seemless

[Kris_Toff]

I am not sure if Jonathan (jmarshall) wants us to continue the discussion here about suggestions on how this could be implemented, so until then...

Tell me if I am wrong but I suspect that in order to work, a ListItem implementation requires the "ListItem array of properties" to be loaded. I sense this is different from the fanart implementation which probably just follows a simple expression to construct the fanart filename (movie-fanart.jpg)...

Parsing an xml file maybe taking a little more time but we are talking about xml here so a fairly good structure like this could load in no time. Let me expand on that:

In comparison with the Enable Tag Reading from the audio section (which is read from binary files), I believe we wouldn't see a performance issue at all (unless there are hundreds of movies in one folder which would beat the purpose of using folders and not the video library). In order to read the audio tags, the whole file must first be "opened", i.e. several Mg per file... An xml file like this would at the MAX be 4k and would be parsed in ms, even on a VERY old xbox.

In term of supporting this, I don't think it requires a full setup file section on a per folder basis. I think kraqh3d's suggestions makes sense. What about just just adding a "Enable NFO file reading" option in Settings/Video/General/ or even a duplicate of the settings for audio tags (Settings/Video/Files/ with matching template filename expression) ?

I'll leave to the expert a way to deal with the database but something like the Audio tags for video seems the right way, less difficult, and faster to implement. (maybe before november ?...)

My 2 cents...

Jonathan, does it make sense?
Thanks

[kraqh3d]

I didn't say (this time) to use library mode I simply said things would be a lot faster using the DB from library mode to get the tags.

its not as easy as this seems. the database is not file oriented. its content oriented. and, to further complicate things, its stack reliant, which means the file "pointers" in the database do not necessarily match those in files view.

(this works for music because it is pretty much file oriented. a song is a file, or part of a file. but there are only songs, not other content types, and its never that a song is made up of multiple files.)

[jmarshall]

No features will be implemented before November, simple as that. You are either going to have to wait, or do something about it yourself.

You are free to discuss it in the meantime, ofcourse.

Cheers,
Jonathan

[kraqh3d]

@Kris_Toff
to answer ur question in the 'other' thread... no, it is not possible today, but entirely possible with not too much work. all the bits necessary are already in the code. they need to be reorganized differently. (i say this like its trivial, but admittedly, xbmc's source code can be overwhelming to a newcomer.)

regardless, xbmc is in a feature freeze so nothing is going to change for a bit, and even if its does, it may not do what you want. but since xbmc is fully open source, you are always welcome and encouraged to make changes to suit your own needs, and submit patches.

but, further discussion is welcome. i personally liked britneypairs idea to only load the nfo data on playback so that the overlay gets populated. this happens for music files.

[BritneysPAIRS]

It accually does get filled now on playback ....

I was thinking of making a patch that would load the nfo if there was a call for fanart.jpg, I think for most users they only want this with conjunction of fanart so if a successfull filename-fanart.jpg or folder fanart.jpg is loaded ill load the nfo data.

If anyone wants to help or has other ideas it should be pretty easy (would prefer it to be in source of course but as it will be months away at least and shouldnt be to hard I can do a patch for myself at least)

[jmarshall]

The way it I'd like to see it done:

1. Split the scanner into two - one for filebased stuff (thumbs, nfo, tags for mp4 etc.), which we'll call a tagger, and one for net based stuff, which is a scraper.

2. The tagger can check the db for information before loading local info.

3. Allow the tagger to run at any time (i.e. in file mode) and to inject the information in to the database if required (scanning).

4. Allow the scraper to run only at scan time, after the tagger has run.

One obvious problem is updating of information. As we have information from both local (tagger) and online (scraper) sources, we don't know which one a particular piece of information came from. We'd hash the path in the same way as is done now, but would include .nfo files in the hash so we know when they've been updated. Local information should take priority over online information at all times, though there's no reason why it can't be supplemented by online info.

Cheers,
Jonathan

[BritneysPAIRS]

I know you guys would do it properly, for me I was just going to make a hack to load the info tags with current list item if fanart is being loaded (my skills are very limited), this would suit most peoples needs I would say. Just a simple hack I guess. I guess I should also look to see if an nfo is there and load it if it isnt in the database as well. And a vis tag for is fanart true/false would be nice if one isnt there now... ill check tonight when I hack things up.

[kraqh3d]

some comments...

its easy enough for the "tag reader" to add content to the database as the content-type is defined in the nfo xml file (ie, its <movie> or <episode>, etc). stacks still stand out in my mind as an annoyance.

looking for matching content in the database first (so as not to keep reading the nfo file every time) would require the content-type to be set for the folder. (and the way xbmc stores this today is not well suited for this type of access. xbmc only tags the path where content is set, not all the sub paths, so we have to find the "longest match.)

if content is not set, then xbmc will have to check the movies, episodes, and musicvids tables, in turn, until it finds a matching file id that matches the file. (and again, stacks will pose a challenge.)

regarding stacks... after the feature freeze, i plan on adding "autostacking" for the library for movies and music videos, like exists today for tvshows and episodes. this will ease the problem, if we stop the scanner from stacking beforehand. the scanner could add each individual file to the database, linked to the same movie. but stacking takes processing time, and the larger the library, the longer it takes. (just like in files view.) and xbmc will still need to account for databases which contain stack:// urls from previous scans.

[Kris_Toff]

some comments...

looking for matching content in the database first (so as not to keep reading the nfo file every time) would require the content-type to be set for the folder. (and the way xbmc stores this today is not well suited for this type of access. xbmc only tags the path where content is set, not all the sub paths, so we have to find the "longest match.)
...

I have a question, would xbmc cache the nfo files once they have been read ?

I am still not convinced that reading all the nfo files would be such an annoyance, specially if this is cached.

BUT, I like the BritneysPAIRS's suggestions to load it as fanart.jpg is called. (that should still be an option in settings).

I made a little test on a very old linux box (700Mhz...) that I use as an archive server. I wrote a little C prog that opens 100x nfo files (average size about 5k), read all lines into a char * and closes them. The time command returned about 1s for all files.
A time test of a single file returned :
real 0m0.011s
user 0m0.006s
sys 0m0.004s

So if we assume (for a skin view purpose) that when the fanart.jpg is loaded, it would take almost no time to load up the ListItem.variables for the nfo file.
Again, 100 files would be a very big stretch...

That should be sufficient for making nice skins that would go past the single ListItem.label for a movie.

my 2 cents

[pko66]

First, I want to clarify a previous misunderstanding:

"Completely broken" is incredibly harsh, not to mention not true. Just because something is not perfect/appropriate to you doesn't make it broken and unmendable.

When I said "at least for me, library mode is completely broken and cannot even be mended", I didn't mean it to say "my opinion is that library mode is broken", but "for my (very personal and particular way of) using of my movies collection, library mode is broken", its because of that that in the end I say library mode is almost perfect for a certain, more general, use. Hope that nobody got offended for my too ambiguous sentence.

But even so, me saying that cannot be mended was maybe too premature, since with my recently acquired knowledge about scrapers, I have the inspiration that some of the things that bug my particular use of library mode can be corrected.

regardless, xbmc is in a feature freeze so nothing is going to change for a bit, and even if its does, it may not do what you want. but since xbmc is fully open source, you are always welcome and encouraged to make changes to suit your own needs, and submit patches.

Well this particular solution I propose would require, to be properly implemented, some changes in code (to include some more fields in the db like <tag></tag> and some more), but since it is really a hack, it can be hammered in the current, pre-atlantis structure. I will tell the general idea before considering actual implementation.

First, we need some places to insert information in the db. All of the fields are interesting and important, but I feel we can consolidate <tagline>, <outline> and <plot> all together in the <plot> field (in fact, even before this I planned to put <outline> or <tagline>, when there is one, in the <plot> field for movies with an empty <plot>....).

Then, since the IMDB genres are (IMHO) too general, I would put them in the <tagline>. They will be show in "movie info" window so you can know what IMDB thinks about the movie but will not be used in navigation.

So we have now free the multi-instance field of <genre>, and we populate it according to the source. For example, a directory that contains original version subtitled comedies will have <genre>OVS Comedy</genre><genre>OVS Movies</genre>; for the kids' movies directory, it will contain <genre>Kids' movies</genre> and so on. So, navigation by genre is in fact like navigation in directories. I have my movie collection carefully classified in directories and all that clasification gets lost in library mode... not anymore thanks to this hack!

This could solve my 1), 2) and 5) complaints about library mode in my original post. 3) is not so much an issue since you have an alternative navigation. To address 4) [that was that the file may be offline], I could use <outline> tag to insert information like "This movie is in USB disk #4, please connect it to watch the movie" or "This movie is in the 'Vintage' server, please turn it on with the Wake On LAN script if necessary". Not a perfect solution (a script that automatically runs before starting the movie and that shows a dialog if necessary, even waking the destination server, would be much more nice) but a solution nevertheless.

Now, to actual implementation. In pre-atlantis time, the info could be inserted using "settings" of special-made scrapers; I do not know if that can be since I have not yet started the study of scrapers' settings, but I know for sure that another, much more ugly solution, is to create a copy of the appropriate scraper for each source that has the <genre> etc tags harcoded.

In post-atlantis time, the sky is the limit if the programmers want: new fields like the proposed <tag> can be created, an "advanced" windows in "movie info" could exist to enter specific information or to re-scrape a movie with a specific scraper, "partial" scrapers may exist that simply add info to a movie or source in addition to the existing one...