+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)
Resume the discussion? - AnalogKid - 2009-06-03 17:25
Hey Jim,
I wonder if you're back in the mood to discuss this topic?
I know you were snowed under with Babylon, and I expect you're already racing ahead with new ideas for the next release.... but I shall continue to haunt the forum!...
I'd love to be part of the discussion on how to rethink the fanart and thumb situation to hopefully be easier on the code, and less prone to error (I know 99% is working already and user is a big factor, but I still think this should be considered).
I'm happy to detail a whole bunch of discussion points to get the ball rolling if it helps.... I am an ex developer, but my hey day is well and truly behind me... so I can only contribute with what I'm good at... the logic and the extensibility / rationale... which means I have to get significant buy in from a developer to help make it happen.
And this certainly isn't a criticism of all the work that's gone in so far.... just a guy feeling it's been worked and worked to the point that its gotten a little TOO flexible... bulking up the code and leaving the end users so spoilt for choice they can't make it work, and of course we're seeing skinners being creative, but in a skin specific way!
Cheers,
The Kid
- jmarshall - 2009-06-04 00:01
I'm busy researching the new video library. This is gonna be quite a while.
Others may be available to work on this. It is certainly something I'll bring up at devcon in 3 weeks time.
Cheers,
Jonathan
- AnalogKid - 2009-06-04 20:37
Marvellous...
If there's no objection, I'll write down some of my thoughts in this forum - I'm not expecting any to be acted upon, but it might later be used as a basis for some structured decision making.
(Anybody's welcome to add their own thoughts, but I just figure whoever codes it will have a much easier job if some hard thought has already been done and documented before hand).
(just a tad nervous of pi**ing off developers with a perceived condescending wishlist)
- bidossessi - 2009-06-06 11:21
@AnalogKid
I, for one, second your opinion, but i believe this subject really becomes important in a 'NAS-style' storage schema. And i think the Unified Media Manager should be able to solve that issue.
the fact that XBMC can handle several storage scenarios is a plus imho, and something that should be kept, but users should be encouraged to adhere to "media storage best practices" conventionally decided on a sticky somewhere in the forum; which practices could then be enforced by the aforementioned UMM.
Just my 2cents
Proposal For Art Rationalisation... - AnalogKid - 2009-06-06 23:25
ok, here's my initial stab at detailing some of the issues with art (fanart and thumbs etc).
Also I'm detailed some logical (imo) proposals to rectify them.
The fact that artwork can be specified in a number of naming forms would appear to be a good thing at first inspection, but we can see from the forums and scrapers that it's adding complexity to XBMC that probably doesn't need to be there. In addition, this can only increase the code complexity of XBMC also. We have some naming schemas that work in hierarchical systems only, and others that will work in flat or hierarchical. We also have NO way to work with portrait AND landscape artwork schemes simultaneously.
Suggested solution
Artwork MUST be unambiguously named, so that no matter where the artwork exists, it can easily be attributed to the associated media.
A suggested naming convention is given below:
<moviename>.moviefanart.landscape
<moviename>.moviefanart.portrait
<moviename>.moviecoverart.landscape
<moviename>.moviecoverart.portrait
<moviename>.movieframegrab.<n>
<tvshow>.tvshowfanart.landscape
<tvshow>.tvshowfanart.portrait
<tvshow>.<season>.tvshowfanart.landscape
<tvshow>.<season>.tvshowfanart.portrait
<tvshow>.<season>.<episode>.tvshowfanart.landscape
<tvshow>.<season>.<episode>.tvshowfanart.portrait
<tvshow>.tvshowcoverart.landscape
<tvshow>.tvshowcoverart.portrait
<tvshow>.<season>.tvshowcoverart.portrait
<tvshow>.<season>.tvshowcoverart.landscape
<tvshow>.<season>.<episode>.tvshowcoverart.portrait
<tvshow>.<season>.<episode>.tvshowcoverart.landscape
<tvshow>.tvshowframegrab.<n>
<tvshow>.<season>.tvshowframegrab.<n>
<tvshow>.<season>.<episode>.tvshowframegrab.<n>
<artist>.musicfanart.landscape
<artist>.musicfanart.portrait
<artist>.<album>.musicfanart.landscape
<artist>.<album>.musicfanart.portrait
<artist>.<album>.<track>.musicfanart.landscape
<artist>.<album>.<track>.musicfanart.portrait
<artist>.musiccoverart
<artist>.<album>.musiccoverart
<artist>.<album>.<track>.musiccoverart
What are the advantages of this schema?
1) The naming is COMPLETELY unambiguous and predictable
2) The files can exist ANYWHERE on a system (hierarchical, flat, even in a totally different folder or server)
3) For compilation albums where an artist exists on the album, but has no album of their own.... the artwork for that artist can still be discovered.
4) For the new skins that are using a mix of portrait and landscape artwork it's possible to switch skins WITHOUT having to reconfigure artwork (providing the user has provided both orientations)
5) The naming convention is hierarchical, so it's easy to figure that if there isn't an image at say episode level, one might exist for the season, or even the *show level.... so it's pretty granular(even though most skins do not support that level of granularity YET)
6) It's extensible.... so for instance, one day, it might be possible to have multiple fanarts for a movie..and cycle between them just by adding a .<n> suffix
7) It's relatively simple for existence user to port their art to the new format... a script would be easy to write to do this.... so any transition pain would be minimised.
Surely this would massively ease the burden on XBMC and scrapers... however, as far as I know, there would have to be a new API for skinners to use to specifically request portrait or landscape art (with legacy skins supported in the traditional way... with a default of portrait for thumbs and landscape for fanart).
I have also taken into account the possibility at some point some skins MIGHT want fanart and coverart even down to episode and track level. Nobody HAS to use them!
I would be very interested to hear feedback on this proposal....
- szsori - 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.
Some notes for reference... - Gamester17 - 2009-06-07 14:36
Main XBMC wiki about thumbnails for reference => article http://wiki.xbmc.org/?title=Thumbnails
szsori Wrote:FanArthttp://wiki.xbmc.org/?title=FanArt
szsori Wrote:wide bannerhttp://wiki.xbmc.org/?title=Wide_Banner_Icons
See this discussion about different thumbnails for different views (wide vs. non-wide), and how to possibly support using both=> http://forum.xbmc.org/showthread.php?tid=28691
szsori Wrote:16x9 panels (this is TheTVDB's official name for the new Aeon format)More information here: http://forum.xbmc.org/showthread.php?tid=49761 (also informally referred to as "Wide Posters", this is not the same as FanArt because FanArt does not have logos/text).
szsori Wrote:posterPoster exist for both Movies and TV Shows. TV Shows have one generic poster, then also also season specific posters.
szsori Wrote:episode thumb (either 16:9 or 4:3 format)Remember here that Aeon also supports multiple screenshot thumbnails for movies and multiple episode thumbnails for TV Shows. The latest Aeon actually supports multiple thumbnails in the same ("Multiplex") view, currently AEON's Multiplex view supports a 'dual-thumb' mode and a 'big thumb' mode, two is the the minimum:
http://forum.xbmc.org/showthread.php?tid=49559
Meaning one movie can have multiple ("framegrab" as you call them) thumbnails attached for them, and the same for movies, and the same goes for TV Shows. You can almost think of it like a DVD-Video chapter index with one screenshot for each chapter.
For movies they have started collecting them here:
http://forum.xbmc.org/showthread.php?tid=50401
I actually think that support for multiple 'framegrabs' for each video is something that will soon also be picked by other skins for XBMC for both movies and TV Shows.
...then there is also an entirely new HTPC artwork concept called "ClearArt", see:
http://forum.xbmc.org/showthread.php?tid=51705
PS! I also suggest that the file-extension should not be renamed to something that is XBMC specific but should keep the original image format file-extension, like .jpg or .png
- AnalogKid - 2009-06-08 12:10
szsori Wrote: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)
I believe it does address precisely those formats, perhaps with the exception of wide banner (which equally, could easily fit into the schema with a widebanner classification). Fanart is covered, 16x9 or 4:3 could be classified as landscape, but equally it's fine to extend the schema to be more specific and state 16x9, 4x3. Although there probably needs to be SOME degree of sensible granularity... today XBMC has NONE.
Episode thumbs are also covered in the same manner... explicitly as thumbs, but if necessary can be granularised to 16x9 4x3. I would however still argue that 'landscape' MIGHT be enough (with an option to declare aspect ratio if need be). This proposal is an opening gambit remember.... today we have absolutely NO detail about art... other than it's a poster, a fanart, or a thumb... and resolving which art belongs to which media is flawed for music (it's not so bad for Movies)
szsori Wrote: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.TV Series art down to episode level is covered, but again, it's the SCHEMA being discussed... it's extensible...so if you want a logo, the naming scheme can be extended to include such.
Stacking is covered... it's not an issue since XBMC logically can form a logical single movie... it already manages to work today with starwars-Cd1 and starwars-Cd2 using starwars-fanart naming convention. In my opinion stacking is simple a logical union of multiple physical files. Since XBMC can already abstract this away, the artwork doesn't have to worry about it. That said, there is nothing to stop a user having a CD1 and CD2 movie with corresponding artwork for EACH CD in the above schema.
Quote: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 is quite untrue, the logic behind the schema is that it has no correlation with how XBMC's library does or does not work. Nor does it assume any logical organisation of a user's media. It simply affords a user to have their media in any old place, in any old format.... BUT the art for that media can found a) rapidly b) without ambiguity c) with more definitive information about the style of artwork
Scan the fora on artwork / skin issues... it's clearly not as trouble free as you'd like to think. Much of this is down to user error, I grant you...but still the issue remains... users struggle with the plethora of possibilities. This makes debugging harder, more code is involved to cover all the options and we see skinners creating non standard ways of dealing with the issue.
Quote: 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.This isn't missed at all. Library mode is 'deduced' from file mode. In order for library to collate it's info, it must first utilise file mode to find art and media.
The schema is designed for File Mode.... where XBMC can easily deduce the correct artwork to display. The above schema allows for art to be placed ANYWHERE, but I do take your point that for file mode, the end user would still have to 'pair' the media and the art in the same folder if the media wasn't named correctly.... in this situation, the schema fares exactly the same way as today's existing solution, no better, no worse.
Quote: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.Not sure I understand this section... the purpose of my schema is to allow XBMC to find the art it needs, it's down to XBMC what it then does with that art... ie cache it, reference it in the library etc. Same as it does today.
However, part of your suggestion seems to be in line with my thinking... Im no fussy about the actual naming convention, only that it is totally unambiguous and more detailed than the current situation. I disagree with imposing limits of 0-10 though, but I catch your drift.
Quote:For the library items, images could be arranged using any sane structure and the path stored in the images table.Agree here. The purpose of the 'suggested' schema isn't to dictate "MUST" be precisely this, but to act as an example of how the naming could be massively improved to be unambiguous, and more detailed and resolve the issue with the ever increasing range of formats. In XBMC today, if you have your artwork in landscape format (let's forget the aspect ration for the moment), then switch to a portrait style skin.... you need to redo all your artwork. I personally would rather have all my artwork done and dusted in all formats, and then freely switch skins as I pleased.
Both methods would require a list of standardized image formats.
As I stated earlier...Movie naming resolution is actually pretty damn good, but music is more complicated. Finding the correct artwork for music is currently based on a very good logical assumption algorithm, but it's not flawless... and is highly suspect for artist images on compilation albums (dont want to go into details!).
- AnalogKid - 2009-06-08 12:21
Gamester17 Wrote:Main XBMC wiki about thumbnails for reference => article http://wiki.xbmc.org/?title=Thumbnails
http://wiki.xbmc.org/?title=FanArt
http://wiki.xbmc.org/?title=Wide_Banner_Icons
See this discussion about different thumbnails for different views (wide vs. non-wide), and how to possibly support using both=> http://forum.xbmc.org/showthread.php?tid=28691
More information here: http://forum.xbmc.org/showthread.php?tid=49761 (also informally referred to as "Wide Posters", this is not the same as FanArt because FanArt does not have logos/text).
Poster exist for both Movies and TV Shows. TV Shows have one generic poster, then also also season specific posters.
Remember here that Aeon also supports multiple screenshot thumbnails for movies and multiple episode thumbnails for TV Shows. The latest Aeon actually supports multiple thumbnails in the same ("Multiplex") view, currently AEON's Multiplex view supports a 'dual-thumb' mode and a 'big thumb' mode, two is the the minimum:
http://forum.xbmc.org/showthread.php?tid=49559
Meaning one movie can have multiple ("framegrab" as you call them) thumbnails attached for them, and the same for movies, and the same goes for TV Shows. You can almost think of it like a DVD-Video chapter index with one screenshot for each chapter.
For movies they have started collecting them here:
http://forum.xbmc.org/showthread.php?tid=50401
I actually think that support for multiple 'framegrabs' for each video is something that will soon also be picked by other skins for XBMC for both movies and TV Shows.
...then there is also an entirely new HTPC artwork concept called "ClearArt", see:
http://forum.xbmc.org/showthread.php?tid=51705
PS! I also suggest that the file-extension should not be renamed to something that is XBMC specific but should keep the original image format file-extension, like .jpg or .png
The above (IMO) only goes to illustrate my point about a need to reign all this in!... it's great stuff and I love it all, but before it gets too out of hand it would be nice to agree on some principles for how to name and resolve artwork. The existing solutions have worked really well (read VERY well), but are now being pushed to breaking point, hence my quest to try and move forward with something that MIGHT keep the ship stable for a the next couple of years (until we hit the next set of 'issues'). It's a fine balance that one... coming up with something that's flexible enough (but not so over that it tries to be future proof, and fails miserably - 'cos nothing ever is!).
Definitely a hot topic though... which I find encouraging. It seems (so far) that nobody is saying "everything is perfect today". If we agree on that much, then it's progress... because then we can look at how we can improve it.
There's enough smart cookies and dumb ones (that need to be catered for!) to keep XBMC the best out there!
So far in the above Schema I've taken into account the following:
* Fanart (at movie, tvshow, tv season, tv episode, artist, album, song levels) in landscape and portrait orientations
* Thumbs / Cover art (at movie, tvshow, tv season, tv episode, artist, album, song levels) in landscape and portrait orientations
* Framegrabs (at movie, tvshow, tv season, tv episode levels)
And also allowed for the multiple instances of each (for slideshow type effects.. should anybody be crazy enough to make a skin with slideshow fanart.... (read DJH !)).
That said, it's been suggested that 'landscape' and 'portrait' might be too broad a category, and they should be more precise. That's no big deal, it could be extended to (for example) Landscape.16x9.
I'd also abbreviate the naming convention in real life... but this is just a mockup suggestion as an opening gambit.
I've also wondered about making the 'NFO' hold all the artwork info. In this case, we'd create an XML element <Artwork> and define to our heart's content all the artwork we wanted! This way, a user can use any damn naming scheme they like, XBMC wouldn't care... it would just read the tag info to find the artwork.
This might be a nice option... will have to see what others think.
- szsori - 2009-06-08 22:25
AnalogKid Wrote:I believe it does address precisely those formats
My point is that your overall scheme misses some stuff, and doesn't account for future stuff without adding a type at each level. The better solution is to generalize it to allow for any accepted format name instead of trying to specify every format name. It will most likely be easier to program and more efficient that way.
AnalogKid Wrote:This is quite untrue, the logic behind the schema is that it has no correlation with how XBMC's library does or does not work. Nor does it assume any logical organisation of a user's media. It simply affords a user to have their media in any old place, in any old format.... BUT the art for that media can found a) rapidly b) without ambiguity c) with more definitive information about the style of artwork
Scan the fora on artwork / skin issues... it's clearly not as trouble free as you'd like to think. Much of this is down to user error, I grant you...but still the issue remains... users struggle with the plethora of possibilities. This makes debugging harder, more code is involved to cover all the options and we see skinners creating non standard ways of dealing with the issue.
I'm changing the order of your post since this needs discussion first. You cannot solve the XBMC artwork problem without applying the solution to how XBMC actually works. Your solution works perfectly fine for items that exist in the library database, but it doesn't apply to the filesystem method of browsing. You would have to add an entry like the following for it to work:
<stackname>.fanart.portrait
<stackname>.fanart.landscape
<stackname>.coverart.portrait
<stackname>.coverart.landscape
<stackname>.coverart.framegrab
You'd also have to extend that to allow for the other formats as well. On top of this, your method adds a little overhead for library items, but it's not a significant amount. XBMC would really just need to do a filesystem call for each applicable line in your "schema". That's per item in the current library view, but XBMC could really do this before the actual display since the library is stored earlier. Filesystem browsing is an entirely different animal, since you'd have to do a filesystem check for each of the lines I listed above for every item in the current directory, and you'd have to do it every time that directory was loaded (unless XBMC has directory caching). That gets really expensive in terms of performance.
This doesn't even take into account file system items being folders OR files, either. You would either have to look inside each folder for the lines above in addition to looking in the parent folder, or you'd have to store the images elsewhere on disk. Storing them elsewhere makes sense until you take into account how XBMC pulls information from a wide variety of sources. Managing artwork becomes a lot more complex when it can't be stored with the files themselves.
AnalogKid Wrote:In my opinion stacking is simple a logical union of multiple physical files. Since XBMC can already abstract this away, the artwork doesn't have to worry about it. That said, there is nothing to stop a user having a CD1 and CD2 movie with corresponding artwork for EACH CD in the above schema.
As explained in the previous section, files are separate from media entries in the library. That's the overall point I was making. You really need filesystem entries in your scheme which can be properly applied for stacking, at the directory AND file levels.
AnalogKid Wrote:The schema is designed for File Mode.... where XBMC can easily deduce the correct artwork to display. The above schema allows for art to be placed ANYWHERE, but I do take your point that for file mode, the end user would still have to 'pair' the media and the art in the same folder if the media wasn't named correctly.... in this situation, the schema fares exactly the same way as today's existing solution, no better, no worse.
Actually, it improves things by allowing for more types of artwork that fit into defined formats. But it also makes things worse by requiring users to pair files with art. To me that means things are slightly easier on the developers and (possibly) skinners while making things far more complex for the end users. To me that's doing exact opposite of what should be happening. One of XBMC's goals is to make things as simple as possible on end users.
AnalogKid Wrote:Not sure I understand this section... the purpose of my schema is to allow XBMC to find the art it needs, it's down to XBMC what it then does with that art... ie cache it, reference it in the library etc. Same as it does today.
However, part of your suggestion seems to be in line with my thinking... Im no fussy about the actual naming convention, only that it is totally unambiguous and more detailed than the current situation. I disagree with imposing limits of 0-10 though, but I catch your drift.
My idea was to have artwork paths stored in the database for library items (the actual filesystem storage locations wouldn't really matter) and flexible naming for art that exists in the filesystem with the actual media files. This is the same as the folder.jpg, except it allows for a variety of formats and doesn't require that users maintain a completely separate area for their art. Keeping artwork alongside the media itself makes the most sense, especially when you start discussing multiple systems pulling from multiple sources. It's the old concept of keeping associated data close together.
AnalogKid Wrote:Agree here. The purpose of the 'suggested' schema isn't to dictate "MUST" be precisely this, but to act as an example of how the naming could be massively improved to be unambiguous, and more detailed and resolve the issue with the ever increasing range of formats. In XBMC today, if you have your artwork in landscape format (let's forget the aspect ration for the moment), then switch to a portrait style skin.... you need to redo all your artwork. I personally would rather have all my artwork done and dusted in all formats, and then freely switch skins as I pleased.
I've got no problem with extending the way XBMC currently works for exactly the reason you listed. In fact, it's something that I hear a lot about when discussing the various image formats for my site. However, IMHO the solution is to slightly modify the way folder.jpg works instead of breaking the artwork out into a completely separate directory structure. That's where our difference of opinion lies.