2009-06-07, 08:15
Your hierarchy doesn't address the many different formats for images. There's the following:
fan art
wide banner
16x9 panels (this is TheTVDB's official name for the new Aeon format)
poster
episode thumb (either 16:9 or 4:3 format)
Some of those could be classified into landscape/portrait, but others could not. There's also some new formats that XBMC might need to handle down the line, like series logo, for example. You also have to take the stack name into account. Finally, your entire scheme is based on the idea that all of these things are categorized properly into the library. The fact is, if the items are in the library already, then it's really not a big deal to also insert art meta information into the library. This completely misses the more complex filename issue, where files and folders can have artwork without really being tied to a part of the library. I'm not sure how XBMC handles things behind the scenes, but I know it can pick up various folder.jpg's for items that aren't in my library.
As a result, I think the solution is to hold image information in the library for those items and allow [stackedname].[imageformat].[iteration].[extension] and folder.[imageformat].[iteration].[extension]. The .[iteration] would be optional, and would just be a sequential number from 0-10. This should be approximately as fast as the current method, but be slightly more flexible to allow multiple image formats per movie/show/etc.
For the library items, images could be arranged using any sane structure and the path stored in the images table.
Both methods would require a list of standardized image formats.
fan art
wide banner
16x9 panels (this is TheTVDB's official name for the new Aeon format)
poster
episode thumb (either 16:9 or 4:3 format)
Some of those could be classified into landscape/portrait, but others could not. There's also some new formats that XBMC might need to handle down the line, like series logo, for example. You also have to take the stack name into account. Finally, your entire scheme is based on the idea that all of these things are categorized properly into the library. The fact is, if the items are in the library already, then it's really not a big deal to also insert art meta information into the library. This completely misses the more complex filename issue, where files and folders can have artwork without really being tied to a part of the library. I'm not sure how XBMC handles things behind the scenes, but I know it can pick up various folder.jpg's for items that aren't in my library.
As a result, I think the solution is to hold image information in the library for those items and allow [stackedname].[imageformat].[iteration].[extension] and folder.[imageformat].[iteration].[extension]. The .[iteration] would be optional, and would just be a sequential number from 0-10. This should be approximately as fast as the current method, but be slightly more flexible to allow multiple image formats per movie/show/etc.
For the library items, images could be arranged using any sane structure and the path stored in the images table.
Both methods would require a list of standardized image formats.