+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)
- tvdb-scott - 2009-06-07
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
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
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
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.
- tvdb-scott - 2009-06-08
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.
- tvdb-scott - 2009-06-08
AnalogKid Wrote: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.
I actually like this option. It's simple and straightforward, and could be maintained by any of the media management apps. The main question is how fast XBMC can read this on the fly.
- digitalhigh - 2009-06-09
I'd like to point out that MIP/serenity supports DVD cover images pulled from freecovers.net. Right now, it only works on locally stored media, but it would be nice to see this included too, despite the fact that it's not an Aeon feature.
Right now, these files are stored in the format of
moviename/extras/
CD1.jpg
CD2.jpg
front.jpg
inside.jpg
inlay.jpg
MIP then writes a flag to the "skin tag" that says which images are present, and my skin displays them accordingly.
This would work out nicely with AnalogKid's suggestion of leaving everything up to the .nfo tag, as it leaves things a tad more open-ended to those of us who do not, in fact, use Aeon.
On the same lines, it would be very useful (at least to me) to be able to know which titles have what images available, as then the user display could be auto-configured to show the proper images. This would also be applicable in the instance of wide banners versus posters for TV shows, as it would not restrict the user to just one or the other...
- jmarshall - 2009-06-09
As far as XBMC is concerned, a couple of points:
1. I don't care how stuff is laid out - the only interest I have is in efficiency of XBMC's code.
2. Movies in separate folders is IMO the _best_ method of storing stuff. It makes stuff like stacking fast, and the new library will be optimized for this method of storing movies.
3. Unfortunately, movies in separate folders is also the most inefficient in terms of finding artwork on the fly while browsing, as each subfolder needs to be fetched in order to find everything (or alternatively stat several tens of files to check stuff). I wouldn't want a separate folder (such as movie_folder/extras/stuff_goes_here) as that would make it even worse. With filesystems that correctly propogate ctime/mtime to the folder when a change is made that at least means we don't have to fetch the folder unless things have changed.
4. Filenames and extensions should definitely be standardized, but XBMC will ofcourse allow a power user to alter these. The defaults simply need cleaning up. I definitely want to get rid of the tbn extension and the nfo extension for xml files. Obviously the power user can use them if they really want to.
5. One thing to concern yourself with is that filesystems don't allow complete character sets, so compromise has to be made with file naming. Length of filenames should be kept to a minimum (xbox for instance) and some chars simply aren't allowed.
6. Whatever we do, it has to be easily extensible. I'm currently erring on the side of NOT including this info in the main video database (saves having to update it all the time) and instead having a separate dedicated artwork manager. I may well change my mind, depending on how things go.
7. As I said earlier, the new library is my top priority, so what little time I have will be spent on that before I even start to think about this stuff. Whether others want to take it up or not I'm not sure.
Cheers,
Jonathan
- digitalhigh - 2009-06-09
jmarshall Wrote:As far as XBMC is concerned, a couple of points:
2. Movies in separate folders is IMO the _best_ method of storing stuff. It makes stuff like stacking fast, and the new library will be optimized for this method of storing movies.
3. Unfortunately, movies in separate folders is also the most inefficient in terms of finding artwork on the fly while browsing, as each subfolder needs to be fetched in order to find everything (or alternatively stat several tens of files to check stuff). I wouldn't want a separate folder (such as movie_folder/extras/stuff_goes_here) as that would make it even worse. With filesystems that correctly propogate ctime/mtime to the folder when a change is made that at least means we don't have to fetch the folder unless things have changed.
6. Whatever we do, it has to be easily extensible. I'm currently erring on the side of NOT including this info in the main video database (saves having to update it all the time) and instead having a separate dedicated artwork manager. I may well change my mind, depending on how things go.
Cheers,
Jonathan
2. I couldn't agree more. It would also make things a lot easier to handle for the creators of the media manager programs, as it would mean less variables to account for. I recently pointed out a method here that allows for pretty simple automation of the creation of subfolders for every movie in a collection...
http://forum.xbmc.org/showthread.php?tid=47071&page=122
3. I wasn't necessarily saying that I want the extras folder...just that it would be nice if these other images were taken into consideration as well. We just picked an arbitrary location for them so that I had some kind of standard to work with while doing my designing.
6. It would be very cool to have a concise and dedicated system for artwork that works uniformly for all media on all levels. If done properly, it would alleviate the issues with music fanart not showing for album/song levels, or how TV show fanart is sorted out. Could also be used to help promote the little-seen artwork specific colortheme feature (TVDB)...something I'd still really like to see in action.
- tvdb-scott - 2009-06-09
digitalhigh Wrote:Could also be used to help promote the little-seen artwork specific colortheme feature (TVDB)...something I'd still really like to see in action.
May become deprecated due to non-use and less than perfect results in the few instances it's used. It's a big internal debate I'm having.
- digitalhigh - 2009-06-09
szsori Wrote:May become deprecated due to non-use and less than perfect results in the few instances it's used. It's a big internal debate I'm having.
Please don't. I think it's a really great feature in concept...it just needs some pushing and explanation for people to take advantage of. And maybe if you gave a few people the ability to go through and edit the themes that are already there...it could work better.
- AnalogKid - 2009-06-09
OK, here's a revamp of two ideas now... one for filenaming, one for NFO usage.
I personally can't decide between the two... each has merits and issues...
Filenaming Schema
note:
Fanart = Large image / wallpaper, usually full screen representing the media
Coverart = The image you'd expect to see on the front of the box (DVD, CD case)
Banner = A highly oblong image usually landscape representing the media
Framegrab = A snapshot of the media (screen shot) of the playing TV show or movie, not applicable to Audio
Discimage = The image you'd expect to see printed on the DVD or CD media (a round image)
Logo = A 'symbol' associated with the media, usually an iconic logo or symbol
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
<n> = Some number to allow multiple instances of artwork types. e.g. Starwars.movieframegrab.001
MediaInfo = 'Flags' as they are termed today. I felt the term MediaInfo was easier to understand
HasBeenPlayed = 'Watched', but a more generic term to cover Audio and even Images
<moviename>.movie.fanart.landscape.<n>
<moviename>.movie.fanart.portrait.<n>
<moviename>.movie.coverart.landscape.<n>
<moviename>.movie.coverart.portrait.<n>
<moviename>.movie.banner.portrait<n>
<moviename>.movie.banner.landscape<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.discimage.<n>
<moviename>.movie.logo.<n>
<tvshow>.tvshow.fanart.landscape.<n>
<tvshow>.tvshow.fanart.portrait.<n>
<tvshow>.tvshow.coverart.landscape.<n>
<tvshow>.tvshow.coverart.portrait.<n>
<tvshow>.tvshow.banner.portrait<n>
<tvshow>.tvshow.banner.landscape<n>
<tvshow>.tvshow.framegrab.<n>
<tvshow>.tvshow.discimage.<n>
<tvshow>.tvshow.logo.<n>
<tvshow>.<season>.tvshow.fanart.landscape.<n>
<tvshow>.<season>.tvshow.fanart.portrait.<n>
<tvshow>.<season>.tvshow.coverart.portrait.<n>
<tvshow>.<season>.tvshow.coverart.landscape.<n>
<tvshow>.<season>.tvshow.banner.portrait<n>
<tvshow>.<season>.tvshow.banner.landscape<n>
<tvshow>.<season>.tvshow.framegrab.<n>
<tvshow>.<season>.tvshow.discimage.<n>
<tvshow>.<season>.<episode>.tvshow.fanart.landscape.<n>
<tvshow>.<season>.<episode>.tvshow.fanart.portrait.<n>
<tvshow>.<season>.<episode>.tvshow.coverart.portrait.<n>
<tvshow>.<season>.<episode>.tvshow.coverart.landscape.<n>
<tvshow>.<season>.<episode>.tvshow.banner.landscape<n>
<tvshow>.<season>.<episode>.tvshow.framegrab.<n>
<tvshow>.<season>.<episode>.tvshow.discimage.<n>
<artist>.music.fanart.landscape.<n>
<artist>.music.fanart.portrait.<n>
<artist>.music.coverart.<n>
<artist>.music.banner.landscape.<n>
<artist>.music.banner.portrait.<n>
<artist>.music.discimage.<n>
<artist>.music.logo.<n>
<artist>.<album>.music.fanart.landscape.<n>
<artist>.<album>.music.fanart.portrait.<n>
<artist>.<album>.music.coverart.<n>
<artist>.<album>.music.banner.landscape.<n>
<artist>.<album>.music.banner.portrait.<n>
<artist>.<album>.music.discimage.<n>
<artist>.<album>.<track>.music.fanart.landscape.<n>
<artist>.<album>.<track>.music.fanart.portrait.<n>
<artist>.<album>.<track>.music.coverart.<n>
<artist>.<album>.<track>.music.banner.landscape.<n>
<artist>.<album>.<track>.music.banner.portrait.<n>
<artist>.<album>.<track>.music.discimage.<n>
<genre>.genre.fanart.landscape.<n>
<genre>.genre.fanart.portrait.<n>
<genre>.genre.coverart.landscape.<n>
<genre>.genre.coverart.portrait.<n>
<genre>.genre.banner.landscape.<n>
<genre>.genre.banner.portrait.<n>
<genre>.genre.framegrab.<n>
<audioformat>.mediainfo.audio.light
<audioformat>.mediainfo.audio.dark
<videoformat>.mediainfo.video.light
<videoformat>.mediainfo.video.dark
<resolution>.mediainfo.resolution.light
<resolution>.mediainfo.resolution.dark
<studio>.mediainfo.studio.light
<studio>.mediainfo.studio.dark
<source>.mediainfo.source.light
<source>.mediainfo.source.dark
<played>.mediainfo.HasBeenPlayed.light
<played>.mediainfo.HasBeenPlayed.dark
NOTES:
*The very wordy examples given above should be abbreviated at some point, they are here to make the examples more readable. So, for instance, MusicFanart might end up being abbreviated to MusicFA or similar.
*I had envisaged that a user COULD omit the .landscape and .portrait elements, so if they wished... they could simply have a filename like this
Southpark.Season01.tvshowcoverart.jpg
This would give the SAME cover art in both landscape and portrait modes
*The . delimiter might have to be changed to help parsing the filename (because some Media titles use . in the name)
*The seemingly redundant .movie . tvshow .music etc are needed to prevent namespace collisions where Movie / TVshow / Artist items have the same title.
*We might need a way to figure for unicode characters to be encoded in the filename (for the titles). But this problem must already exist with all media right? We just need to clarify how it's resolved / handled
*For MediaInfo files, it's unclear if there needs to be one mediainfo file for EVERY (say) studio, or if it would be possible to create a "disney.mediainfo.studio" file that would be found for any studio containing the word "Disney"
*MediaInfo have "light" and "dark" options, this is because the typical usage of this type of art is to act as an overlay / icon / indicator. Since some skins are light, and some dark... the icon would need to be visible in both cases... hence two versions... I could have relied on these images being monochrome and therefore 'invertible' but I felt this was too much of an assumption. So this way, you can have colour ones if you wish.
NFO schema
<Artwork>
__<Movie>
____<Fanart>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______</Item>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______<Item>
____</Fanart>
____<Coverart>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______</Item>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______<Item>
____</Coverart>
__</Movie>
</Artwork>
I didn't want to go through the entire XML!... it's only a mockup... but.. in making the XML, some things crossed my mind....
There's a bunch of different ways to do the XML schema...this is quite a primitive but simple way. But it's wordy (as XML is), and requires XBMC to find the NFO, parse it, then find the content specified within it.
For this simple example... it's not so bad... but IF we really wanted different posters / fanart per track... then we'd either have a complex XML, or an XML per track. I don't much like either of those options. Something feels 'clever' but 'wrong' about it...
Summary:
For me personally, the filenaming still seems the easiest and best option, even if the elegance of the XML holds some appeal too.
I can't help but think of the extreme cases.... where if I said "give me fanart for Madonna, Ray Of Gold, Track 3".... it would just be easier to find the file than the NFO/XML, parse it, THEN get the file. This would be especially true if a user stored all their art in one folder (flat).
I'm erring still on the side of the filenaming for the above reasons... it's just so much easier in most OS to search for "Madonna.Ray Of Gold*.jpg" and see all the artwork you have associated.
I really like the idea of a user storing all the art in one flat folder... but, I am a stickler for organised media.... which flies in the face of this.. since I like to keep all my associated artwork and meta info WITH my actual media. Regardless, the filenaming schema works wherever you stick it.
Finally I have a question for anybody who might know the answer... what happens in XBMC if the fanart existed in two locations across multiple sources? which takes precedence?...
- jmarshall - 2009-06-10
XBMC will prefer the filenames I should think. Obviously source to artwork will be supported in the normal XML nfo files like it is already. If we need to add more types, then it's done on the scraper side of things.
The big problem will be how the thumb loader caches stuff. Things have to be cached to ensure fast loading, but we don't want to cache too much. There's going to have to be some sort of balance here I think.
Cheers,
Jonathan
- AnalogKid - 2009-06-10
jmarshall Wrote:XBMC will prefer the filenames I should think. Obviously source to artwork will be supported in the normal XML nfo files like it is already. If we need to add more types, then it's done on the scraper side of things.
The big problem will be how the thumb loader caches stuff. Things have to be cached to ensure fast loading, but we don't want to cache too much. There's going to have to be some sort of balance here I think.
Cheers,
Jonathan
I can definitely appreciate this aspect. I would guess there are a few choices to be made along the following lines:
a) If the file is a 'common' artwork... e.g. CoverArt it's a candidate for caching, whilst a Screengrab probably isn't (this is making some big assumptions about a skin though).
b) If the file is large in storage size, then it might be a candidate for caching
c) This could be overkill, but... if the file is accessed regularly, it could be a candidate for caching (although this could be tricky to count access requests for per file)
When we use the term 'cache' are we talking about copying remote media to a local store, or are we talking copying it AND optimising it (lowering resolution, storing it in decoded/'display ready' format) too?
I've also wondered about the need to hash the files to detect changes and therefore update the cache... the only reason I can see to do this is to improve the performance of 'update library'. Off the top of my head, I'm asking myself... is it worth it? I don't mind waiting a little longer as long as the job gets done. There's probably other reasons I've missed, just thinking aloud here!
Finally, for skinners... I wonder if it's possible to request a preference for 'cache' vs 'original' artwork? The only issue here is that if skinners choose 'cache', then what have they gained? and if they choose 'original' what's the point of the cache?
Maybe in the future they will have some way of using cache for general browsing...and when the user focuses on a specific media and needs detailed rendering, then the skin requests 'original'.
For me... this is moving into a slightly different realm about how XBMC optimises the use of artwork. Solving the first issue of how to best find it is the primarily goal (although it could be that they are inextricably linked).
I've been thinking much more about the XML content to find artwork, and I'm increasingly coming to the conclusion that it's overly engineered. One of the reasons I started this thread was that so many end users where having trouble figuring how artwork worked, and even amongst the experienced folks, there were too many possible schemas. Putting the artwork references inside XML is neat, but I feel it will only make matters worse still.
"Keep it Simple" is still the right way to go I believe, and for that reason I'm more and more in favour of the filenaming scheme.
I've also come across a few other threads where it's suggested folks (skinners?) would like more and more info on the artwork... like dimension size etc. Well.... there has to be a cutoff point somewhere. For me, that cutoff point should be that the filename should only describe what the artwork does and to which media it belongs.
Does anybody disagree?
Finally, let's say we DID elect to change the filenaming scheme. Would we deprecate the old scheme over a couple of releases, or be merciless and simply enforce a new scheme (but provide some scripts to help people make the transition and give scraper and skinner folks lots of notice)?
I would guess initially, skins would not be broken, they simply wouldn't be able to utilise the new flexibility.
The consequences are clearly quite large... the wiki instructions, and scrapers would all be affected (but this doesn't make it a bad thing... and it will only get worse the longer it's not addressed).
We're a long way off this yet... I appreciate that... just raising the point :-)
- AnalogKid - 2009-06-14
Extended the scheme to include Media Flags, Genres etc...
For me, the file naming scheme seems to be coming together.
Jim seemed to suggest the file naming scheme was the possibly the preferred option, and having thought about it a lot, I'm in agreement.
Would still be interested in hearing counter arguments - or other possibles naming schemas...
Sadly, it seems most folks are too excited by new skins, and rushing ahead to find new ways to enhance the skins with 'tricks' rather than take a step back and fix the naming schemes... but I'm going to carry on until the skin fans finally say "hey, we need to neaten up the filenaming!"