Use of FanArt (and NFO files) in file-mode?

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

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

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

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

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)

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

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.

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.

kraqh3d Wrote: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

First, I want to clarify a previous misunderstanding:

airyphary,214284 Wrote:"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.

kraqh3d Wrote: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...