[MaxNL]

Looking in the forums, especialy lately, there has been a lot of people talking abut media flagging (me being inside this list)... and probably it's all dh fault for his AEON skin .
So I started thinking about this and I would like to share my thoughts and make them a request too (only if you guys think it's a good way to do)
1) Assumption
1.1) Every single media file can have a .nfo description file
This file should have a rigid standard name - so it should be figured out how to handle folder, file and naming convention for every kind of file.
Of course when I mean every single media file I mean: video, audio, picture, playlist, plugin, etc etc
1.2) If a .nfo is not present then the system fall back at the actual behaviour
1.3) Only the structure of the nfo should be established and indication on the "fix" tag
1.4) As xml can rappresent collections everything is written below should be threated as a poddible collection structure (to keep it simple enough no hierarchy available - I'm making a huge sacrifice on this ) with the possibility to make a "default" declaration in each collection
3) DB
3.1) When scanning for media file XBMC check first for the presence of an nfo file
3.2) If not present fall back on the actual behaviour
3.3) If present it scan it and put "all" the data in the DB
3.4) For the already established data - like title, credits, etc etc - no need to change the behaviour
3.5) For every tag not recognized as "established" then use a new table made by a key, name, value structure where the key is the primary unique index, the name is the xml tag from the nfo file and the value is whatever was the value of the tag, of course there should be a link between this table and the media file
4) Skin
4.1) xbmc publish every single field of the database
4.2) for the established data as said before no need to change
4.3) for the new tag xbmc should publish them in two different way
4.3.1) All the data are made available using the tag name (column name of the database table)
4.3.2) All the data are made available using a function that return, for the selected item, the value of the record with the name euqals to the one used in the calling parameter

I know it's a really rough exposition but I think should be enough to discuss a little about that and maybe it should get into the trac request

Bye to everyone
Max

[jmarshall]

I suspect a general key/value pair table would be slow as molasses for directory retrieving in general.

It could perhaps be read in a background thread, however. i.e.

1. All essential information in the main movie/episode tables, so a single query for the list of items. This allows the list to be populated and sorted as quickly as possible.

2. A background threaded query for additional information, which would use the unique id and would just fill in listitem properties. This could either be done on directory retrieval for all items or done on request of information from the skin (i.e. queue up all requests and process them FIFO).

The major problem with this is that we don't want to have to be re-querying things all the time - this is just plain silly (and yes, it's already done in many circumstances such as for thumbs + fanart). The real trick is to ensure that once the information is retrieved from the db once, that we don't have to do it again unless the db information has changed. Some sort of a local cache of information (map<id,info>) for instance would be useful, whether it be kept in memory or on disk. This is faster than re-querying the db (mainly as it saves formatting things up).

Cheers,
Jonathan

[MaxNL]

It could perhaps be read in a background thread, however. i.e.
Some sort of a local cache of information (map<id,info>) for instance would be useful, whether it be kept in memory or on disk. This is faster than re-querying the db (mainly as it saves formatting things up).

I think this could be the key to get to have this work...