2009-04-10, 18:34
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
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