[digitalhigh]

Only argument I could possibly have with the scheme you're presenting is the requirement for the inclusion of the stuff like <moviename> and "movie".fanart.landscape. Seems a tad redundant, no?

Personally, I think a more simplified approach would be to just use fanart.landscape, fanart.portrait, etc.

And studio logos should be white...colors can be rendered in the skin...

[AnalogKid]

Only argument I could possibly have with the scheme you're presenting is the requirement for the inclusion of the stuff like <moviename> and "movie".fanart.landscape. Seems a tad redundant, no?

Personally, I think a more simplified approach would be to just use fanart.landscape, fanart.portrait, etc.

And studio logos should be white...colors can be rendered in the skin...

The reason for the (seemingly redundant) 'Movie' is to prevent namespace collisions with other types of art... so for instance, if you have a Movie and a TV Show or Music artist with the same name, it would be impossible for XBMC to know which was which...

e.g.
Genesis.fanart.landscape (movie)
Genesis.fanart.landscape (music)

Given this scenario, there's a namespace collision, which is why it's necessary to have:

Genesis.movie.fanart.landscape (movie)
Genesis.music.fanart.landscape (music)

This allows for ALL artwork to be placed absolutely anywhere in a filesystem... rather than XBMC depending on folder structures (there are some other reasons too, but I want to keep this simple!). So a user can have all their artwork in one folder if they wish (which could help XBMC significantly when scanning for art)... I did mention this in the small print of 'logic' behind some of the choices, but thanks for the feedback... it's good that people are reading and thinking about stuff.



As for the studio logos... I considered White only... but this is flawed... it's true you can colourize in the skin, but it's still monochrome. I allowed for a genuine 'colour' (multiple colour) logo (of course it would look best with transparency)... and this could not be achieved in the skin, hence I opted for 'dark' and 'light', with no assumptions of the colour depth.

[digitalhigh]

The reason for the (seemingly redundant) 'Movie' is to prevent namespace collisions with other types of art... so for instance, if you have a Movie and a TV Show or Music artist with the same name, it would be impossible for XBMC to know which was which...

e.g.
Genesis.fanart.landscape (movie)
Genesis.fanart.landscape (music)

Given this scenario, there's a namespace collision, which is why it's necessary to have:

Genesis.movie.fanart.landscape (movie)
Genesis.music.fanart.landscape (music)

This allows for ALL artwork to be placed absolutely anywhere in a filesystem... rather than XBMC depending on folder structures (there are some other reasons too, but I want to keep this simple!). So a user can have all their artwork in one folder if they wish (which could help XBMC significantly when scanning for art)... I did mention this in the small print of 'logic' behind some of the choices, but thanks for the feedback... it's good that people are reading and thinking about stuff.



As for the studio logos... I considered White only... but this is flawed... it's true you can colourize in the skin, but it's still monochrome. I allowed for a genuine 'colour' (multiple colour) logo (of course it would look best with transparency)... and this could not be achieved in the skin, hence I opted for 'dark' and 'light', with no assumptions of the colour depth.

Your logic makes sense. I obviously said something about the filename stuff simply because I've already got all my fanart named in the method I mentioned, and I'm not totally nuts about having to rename everything to a new standard...although I'm not totally opposed either.


Perhaps for the studio logos, you could call them "mono" and "color" then? I'd wager that if you call them light and dark, then people are gonna get confused and try submitting mono ones in black...just call it what it is instead and save on any possible confusion.

[AnalogKid]

Your logic makes sense. I obviously said something about the filename stuff simply because I've already got all my fanart named in the method I mentioned, and I'm not totally nuts about having to rename everything to a new standard...although I'm not totally opposed either.

I too am using a scheme similar to the one I've proposed, and have a script to 'transpose' them all into whatever scheme XBMC wants me to have them.
I'm quite happy to help create a 'renaming' script for users to move their existing names to the new ones, otherwise it's a PITA.
That said, the purpose of a new naming convention was to rid us all of the multiple conventions, AND to improve the scheme to offer more options for skinners and end users ('cos we know that today, you can only be a portrait or landscape thumb fan... but you can't be both!).

Perhaps for the studio logos, you could call them "mono" and "color" then? I'd wager that if you call them light and dark, then people are gonna get confused and try submitting mono ones in black...just call it what it is instead and save on any possible confusion.

Right, I can buy into this!... so 'Mono' would be White art on transparent background, and the skin can then XOR (or whatever it needs to do to blend with the skin). and 'Colour' would be colour art on transparent background, with no blending required. Perfect, I will update the spec with this suggestion!


ps. I personally think this is starting to look quite good, and will also help the scrapers too. The old naming schemes have been really good so far, but they are starting to creak under Aeon's strain! (and other skins)... plus, using this scheme is totally unambiguous. There's no danger of putting the art in the wrong folder, or wondering if 'folder.jpg' will take priority over folder.tbn' etc.

p.p.s This is still FAR from a done deal yet!... since somebody has to code it, and there might well be some strong opposition to it. However, I'm hoping most folks will sit back and think "let's go for it".

[AnalogKid]

OK, I've updated the Schema once again based on some feedback from DigitalHigh regarding the Studio Logos.

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>

Examples:
Star Wars.movie.fanart.landscape.01.jpg
Superman.movie.coverart.portrait.jpg

[COLOR="Black"]Regex for the above is:
(.*)(\.movie.*)$



<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>

Examples:
Friends.tvshow.fanart.landscape.jpg
The Simpsons^01^12.tvshow.framegrab.04.jpg

Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.tvshow.*)



<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>

Examples:
Madonna.music.fanart.landscape.jpg
Bon Jovi^Greatest Hits.music.coverart.jpg

Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.music.*)



<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>

Examples:
Rock.genre.fanart.landscape.jpg
Comedy.genre.fanart.landscape.02.jpg

Regex for the above is:
(.*)(\.genre.*)$



<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.colour
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.colour
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.colour
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.colour
<source>.mediainfo.source.mono
<source>.mediainfo.source.colour
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.colour
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.colour
[/COLOR]

Examples:
mp3.mediainfo.audio.colour
h264.mediainfo.video.mono
true.mediainfo.HasBeenPlayed.mono
fr.mediainfo.subtitle.mono

Regex for the above is:
(.*)(\.mediainfo.*)$






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, Music.Fanart 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.tvshow.coverart.jpg

This would give the SAME cover art in both landscape and portrait modes

*The ^ delimiter is used to allow media titles to have '.' character in them, and makes parsing very easy

*The seemingly redundant .movie ".tvshow" and ".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 ".mono" and ".colour" 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.
Just to make this clear....
".mono" = White logo on transparent background... Any skin can then colourize the image to fit the skin theme accordingly
".colour" = Full Colour logo on transparent background... so a skin should just display the logo 'as is'

[bidossessi]

you should probably add subtitle files in there where it applies; which raises the issue of subtitle language code.

[AnalogKid]

you should probably add subtitle files in there where it applies; which raises the issue of subtitle language code.

Do you mean an 'icon' for subtitles exist?

Or do you mean a naming convention for subtitles?


I am limiting the naming convention purely to artwork at the moment, I'm not going to try and resolve subtitle naming formats, or music naming formats etc.

Not being negative, just wanted to take one step at a time and try and make artwork easier to deal with first!

If you did mean an icon for 'subtitle exists' then this is logical, if there's potentially a subtitle icon for each language... I might have to think about that (it's easy to come up with a scheme, but would a skin really show 5 icons for 5 subtitle languages?)

Interesting to hear your thoughts on that...

I could just have

<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.colour

Where lang is a 2 digit code, e.g. UK, DE, FR or 'Generic'. Meaning a skin can pull the 'generic' if it will only ever show 1 icon, and pull specific versions if it really wants to show each language.

[AnalogKid]

I've added the regex required to parse the filenames, and added support for subtitles also. Also fixed the '.' issue in media titles... using the '^' character as a field delimiter will allow any number of '.'s in the fields.



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>

Examples:
Star Wars.movie.fanart.landscape.01.jpg
Superman.movie.coverart.portrait.jpg

[COLOR="Black"]Regex for the above is:
(.*)(\.movie.*)$



<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>

Examples:
Friends.tvshow.fanart.landscape.jpg
The Simpsons^01^12.tvshow.framegrab.04.jpg

Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.tvshow.*)



<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>

Examples:
Madonna.music.fanart.landscape.jpg
Bon Jovi^Greatest Hits.music.coverart.jpg

Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.music.*)



<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>

Examples:
Rock.genre.fanart.landscape.jpg
Comedy.genre.fanart.landscape.02.jpg

Regex for the above is:
(.*)(\.genre.*)$



<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.colour
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.colour
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.colour
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.colour
<source>.mediainfo.source.mono
<source>.mediainfo.source.colour
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.colour
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.colour
[/COLOR]

Examples:
mp3.mediainfo.audio.colour
h264.mediainfo.video.mono
true.mediainfo.HasBeenPlayed.mono
fr.mediainfo.subtitle.mono

Regex for the above is:
(.*)(\.mediainfo.*)$






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, Music.Fanart 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.tvshow.coverart.jpg

This would give the SAME cover art in both landscape and portrait modes

*The ^ delimiter is used to allow media titles to have '.' character in them, and makes parsing very easy

*The seemingly redundant .movie ".tvshow" and ".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 ".mono" and ".colour" 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.
Just to make this clear....
".mono" = White logo on transparent background... Any skin can then colourize the image to fit the skin theme accordingly
".colour" = Full Colour logo on transparent background... so a skin should just display the logo 'as is'

[digitalhigh]

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

You should also add an "Inner" or "Inside" texture...a lot of the movies in my collection have the inlays for the DVD cases as well.

Oh, and for TV shows at the episode level, maybe consider using S01E02 instead of the ^ symbol? Shouldn't be too hard to pull with a regex, and it would still be a tad easier for someone to use via the naked eye, you know?

[AnalogKid]

You should also add an "Inner" or "Inside" texture...a lot of the movies in my collection have the inlays for the DVD cases as well.

Oh, and for TV shows at the episode level, maybe consider using S01E02 instead of the ^ symbol? Shouldn't be too hard to pull with a regex, and it would still be a tad easier for someone to use via the naked eye, you know?

I did think about the inner and rear cover stuff... and abandoned it as 'overkill' however, thinking about it, there's no harm at all in specifying it, even if no skin will ever use it. I will add this.

I'm in two minds about the S01E02... I half agree with you. But I also like consistency with the other names (Artist^Album^Track).
That said, I've also said that the long winded names should be shortened, I just kept them long for the moment for folks to be able to read better. With that in mind S01E02 might be better (although it's not shorter than ^01^02)

Grrrr this consistency thing still niggles me... BUT S01E02 is kinda standard these days.
hummm so a season thumb would be:

House.S01.tvshow.coverart.portrait

and episode thumb would be:

House.S01E02.tvshow.coverart.portrait


I guess that works well enough.




Just out of curiosity, since you're a skinner (or modder) of some repute...
When you wanted to render say a portrait thumb for a music album, you'd somehow have to ask XBMC for "artist^album^coverart.portrait" right? .... and XBMC would try to give you the art you requested.
I'm just curious what XBMC should happen if it doesn't exist... should XBMC return nothing, or should it return the next best thing "artist.coverart.portrait" (so it's like a hierarchy... if it can't find art for such a detailed element, return the higher level of art?). Just thinking out aloud here... but your opinion would be interesting.

[jmarshall]

I'm sure it'll be trivial to find an album, movie, artist or show that has a ^ in it's title.

IMO no matter what "separator" you choose, someone will come up with a case that isn't handled.

[digitalhigh]

Grrrr this consistency thing still niggles me... BUT S01E02 is kinda standard these days.


hummm so a season thumb would be:

House.S01.tvshow.coverart.portrait

and episode thumb would be:

House.S01E02.tvshow.coverart.portrait


I guess that works well enough.

LOL...niggles. And, while I know what you're saying about consistency, I think the deviation for TV shows would be most understandable to anybody who looks at it.

Just out of curiosity, since you're a skinner (or modder) of some repute...
When you wanted to render say a portrait thumb for a music album, you'd somehow have to ask XBMC for "artist^album^coverart.portrait" right? .... and XBMC would try to give you the art you requested.
I'm just curious what XBMC should happen if it doesn't exist... should XBMC return nothing, or should it return the next best thing "artist.coverart.portrait" (so it's like a hierarchy... if it can't find art for such a detailed element, return the higher level of art?). Just thinking out aloud here... but your opinion would be interesting.

I made a skin called "Serenity", and haven't really had time to dedicate to polishing/updating it as of late. I should point out that my skin does utilize the inside DVD images...hence my suggesting it.

But, to answer your question...I would prefer that a fallback image be in place in the instance you described. If using a coverflow view or something similar, it would obviously look much better to have some specific artist image in place as opposed to the default image repeated a hundred times.

Same for TV shows...looks sloppy if an episode thumbnail is missing...would be better to use a thumb of the fanart or something.

Oh, and you can also choose whether to use banner of poster images in serenity for TV shows...meaning a dual set of images for shows would be a really cool feature to get at.

[AnalogKid]

I'm sure it'll be trivial to find an album, movie, artist or show that has a ^ in it's title.

IMO no matter what "separator" you choose, someone will come up with a case that isn't handled.

It's possible, but it's gonna be a lot less common that '.' (28 days later...) (Mr. & Mrs. Smith) etc.

Just out of curiosity, as I understand xbmc today, each instance of a media object (say a movie) has a thumb and fanart right? and the skinner can request the associated art (or ask XBMC to fill a graphics object with the chosen art).

To handle a request for landscape or portrait... XBMC would need to link to fanart.landscape, fanart.portrait, thumb.landscape and thumb.portrait etc? and if so... would this impact on the DB heavily?
If it was mandated that all artwork be stored in a flat folder...then XBMC wouldn't need to maintain a link to that artwork files...it could pull them on the fly ;-)

I would also expect that if anybody DID agree to code this for xbmc, then some elements might not be supported (like inner sleeve covers etc). There'd be no harm in specifying a naming convention, but doesn't mean XBMC has to support the more obscure artwork elements.

[digitalhigh]

I would also expect that if anybody DID agree to code this for xbmc, then some elements might not be supported (like inner sleeve covers etc). There'd be no harm in specifying a naming convention, but doesn't mean XBMC has to support the more obscure artwork elements.

I would think that, from a coding standpoint, it would be much more efficient to just account for all the variables in one fell swoop, instead of adding some image types and not others. If you're gonna do a massive image overhaul, present every option at once and get it over with.

I raised the issue a while ago of accounting for both banners and poster images, and the response was something along the lines of "that's a lot of work for something few people would probably want". Mind you, I'm just paraphrasing from memory.

Point being, if you're gonna account for CD images and DVD covers, then throw in the inner stuff and be done with it now. Encompass as much as we can think of now, so that it doesn't need to be done in the future...

[AnalogKid]

I would think that, from a coding standpoint, it would be much more efficient to just account for all the variables in one fell swoop, instead of adding some image types and not others. If you're gonna do a massive image overhaul, present every option at once and get it over with.

I raised the issue a while ago of accounting for both banners and poster images, and the response was something along the lines of "that's a lot of work for something few people would probably want". Mind you, I'm just paraphrasing from memory.

Point being, if you're gonna account for CD images and DVD covers, then throw in the inner stuff and be done with it now. Encompass as much as we can think of now, so that it doesn't need to be done in the future...

I think that gets my vote.
One of the reasons I wanted to standardise all this wasn't just because there were missing artwork types, but because the there were a number of naming conventions being used (folder.jpg, movie.jpg movie.tbn etc), and a quite disturbing case of having to name a file 'jpg' even if it was a png! I just felt that all the flexibility was starting to make life harder for end users and not easier. Plus, I figured the code was getting messier and messier (just a hunch). When some of the more adventurous skins came along... it only added weight to an overhaul of the artwork system.
I think you're right that folks immediate reaction is 'it's not necessary / too much work'. But I think when folks really think about it, it makes sense to do this before things get even worse. Sadly it's not as 'sexy' as some stunning new XBMC feature... but I think it will give rise to some more sexy skins and reduce the number of 'my artwork isn't showing' questions from noobies (and sometimes old timers!)

I will add the inner cover stuff later today, there can't really be many more image types left.

One other thing I've worried about... is the term 'Landscape' and 'Portrait'. These are quite generic terms, and I did not want to go any more detailed than this (e.g. dimensions!). I had envisaged that if a skin wanted a portrait image, it could ask for one... but that it may have to stretch the image a little to fit very precise dimensions. The same with Landscape. I did not want to get down to '4:3' '16:9' etc. In my opinion, this is good enough.
For CD covers I was in a dilemma; either I omit the orientation completely, make 'portrait' mean 'square/portrait' or introduce an orientation of 'square' too. I choose to just omit the orientation... but open to other points of view on this one!