[tetsuo55]

What about putting cast and crew under "mediainfo"

[MaxNL]

...
So here's my take:
The art in the current spec is all art that can be associated with a media file PURELY based on it's name.
So The movie covers etc and music are all figurable without needing the internet or additional file (no NFO is needed).
However, actor art, year etc etc all need additional movie info to the pulled from the net (scrapped) and then linked to art.

Tier 1:

All the artwork that an reasonably be associated as representing / promoting a specific media file and requires no specific movie meta data. e.g. Posters, Banners, Covers, Disc images etc... stuff that is usually specific to one media file (or entity)

Tier 2:

All 'associated' artwork that does not represent / promote the specific media, but instead represents attributes of a movie. e.g. Actors, Crew, Location, Year etc... stuff that could be shared across multiple media files (or entities)

I think the 2-tier approach is the right one too. I also hate to draw lines but at the moment I think is the best we can do.

Looking at your previous post we should take out from the actual proposal the following elements:
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
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

As I think they are of Tier-2 type. Am I right?

Regards
Max

[AnalogKid]

I think the 2-tier approach is the right one too. I also hate to draw lines but at the moment I think is the best we can do.

Looking at your previous post we should take out from the actual proposal the following elements:
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
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

As I think they are of Tier-2 type. Am I right?

Regards
Max

Yes you are right... they were really there from the early days of the proposal to demonstrate how the scheme could be used for artwork not directly related to a specific media.

I don't mind keeping them and adding some more ideas like Actors etc...but as a 'tier 2' option. The only issue will be that it might detract from the main event (the media art!).

Also, I've been thinking about 'Actors'. This is problematic just because of the actor names (esp if they have characters that the file system doesn't support)... there's not quick and easy way to give an alias/fsfriendly name in the NFO. This is partly why I liked 'truename.txt' solution over the NFO.

I'll think about this some more.
But again, you are quite correct that the mediainfo and genre stuff is absolutely 'Tier 2' art!

[digitalhigh]

Yeah, I think the actor stuff is fairly well handled in XBMC as-is. In fact...I've never had to manually add any of those images...the scraper has always done it perfectly for me.

However, they should def. be tier-2 stuff, as, well, I don't want to have 1000 different pictures of Kevin Bacon floating around on my media HDD.

[AnalogKid]

I updated the 'tier 2' stuff a little... and put a big caveat in there about this work:

http://www.xbmc.org/forum/showpost.php?p...tcount=185

To DigitalHigh's point about scrapers already handling actors well... hmmm, I didn't want end users to have to depend on scrapers to get artwork, but I definitely also don't want to get bogged down in this Tier 2 stuff either.

I think the next biggest task will be to find a really good sponsor for the Artwork spec. I definitely expect it to be hit with a whole load of resistance from the XBMC developers initially on the grounds of the following:

• It ain't broke, so why are we fixing it? (ill considered argument I think)
  
• I'm not motivated enough by it, so won't code it
  
• Too busy
  
• It's quite a significant change and we are scared to make a big change
  
• Too complicated (I think we can win this argument)
  
• Is this crap for Aeon, it sure looks like it (I think the can win this too!)
  
• Nobody wants it (We can win this)
  

[AnalogKid]

I don't know a great deal about skinning at the moment, but I know DigitalHigh does...

I'm curious if my understanding is correct here:

To BEST utilise this proposed scheme... changes in the skinning engine would be required to get the extra art. BUT, it should be possible to use the new scheme without needing to change any skin code... but then skins could only display the thumb and fanart as normal.
The skinning engine would simply transpose 'thumb' to mean frontcover (portrait) and fanart would remain as fanart (landscape). In the case of multiple instances of frontcover or fanart, the engine would only ever user the first instance.

Would this assumption be correct?

I am hoping that this would ease the worry that 'EVERYTHING' will be broken by moving to this new artwork scheme.

[tetsuo55]

If anyone interested in this knows how to code a patch could be written, which would make acceptation that much easier.

Also (at least for now), the current method should still be available as a fallback (and then gradually get phased out)

I think the 2 tier approach is a very good idea.

[digitalhigh]

I don't know a great deal about skinning at the moment, but I know DigitalHigh does...

I'm curious if my understanding is correct here:

To BEST utilise this proposed scheme... changes in the skinning engine would be required to get the extra art. BUT, it should be possible to use the new scheme without needing to change any skin code... but then skins could only display the thumb and fanart as normal.
The skinning engine would simply transpose 'thumb' to mean frontcover (portrait) and fanart would remain as fanart (landscape). In the case of multiple instances of frontcover or fanart, the engine would only ever user the first instance.

Would this assumption be correct?

I am hoping that this would ease the worry that 'EVERYTHING' will be broken by moving to this new artwork scheme.

It really depends on how the person coding it decides to implement the newly available images. Like I laid out in a previous post, I think it would be best to call everything (something along the lines of) listitem.image(IMAGENAME,variable) where IMAGENAME is the type, and variable would be the orientation, or imagenumber, or whatnot.

However, like tetsuo55 said, it would be really stupid to remove the current listitem.thumb/listitem.fanart/etc infolabels, as it would break every other skin out there.

The best approach would be to allow for either infolabel to produce the image, and then slowly ask the devs to depreciate the old methods as the new ones are used. This is what was done when new features like grouplists and such were added.

So, no. If a coder were to approach it correctly, it wouldn't break anything.

[Gangsta]

Id still love to see an option added for this in the settings, a simple yes/no asking if your using the new schema. the 'improved' skinning engine looks at this, if its 'yes' then it totally jumps all the old code, and breaks old-style skins. BUT. we get a nice speed improvement due to our optimized filenaming if we use a skin the supports the new schema. if its 'off' then it runs the existing code.

I would absolutly hate to see both bits of code running side by side. Even during a changeover period - it would be horrible.

EG. the user makes a concious decision to upgrade to the new schema, and get its all its benefits.

[xexe]

I think it is time to take a pause and petition for a dev to sponsor your idea.

Without one of them you could be wasting your time.

I would recommend putting the whole scheme on a wiki page somewhere nicely formatted and link to it here... no dev is going to read all this thread and you dont want them bailing out of boredom.

[AnalogKid]

I've created an online wiki that helps keep the spec easy to read and understand the rationale:

http://xbmc-media-art-proposal.wikidot.com/

I'm new to wiki's but it seems to work well enough!


I have also submitted a formal feature request within XBMC's trac system, with Trac Ticket #6849

[digitalhigh]

Howabout you give me wiki access, and I'll throw up my proposal for the related infolabels...after I sober up a little.

[AnalogKid]

Howabout you give me wiki access, and I'll throw up my proposal for the related infolabels...after I sober up a little.

Done....

I will create a page called "skin considerations" and you can toss your ideas there!

[Gangsta]

The wiki is looking gooooood. Very easy to read and navigate.

just one tiny (and probably unimportant thing)

the . (dot) is missing in some of the options (or in the wrong place), assuming () means available choices, and green is optional.

<moviename>.movie.fanart(.landscape/portrait).<n>
<moviename>.movie.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<moviename>.movie.poster[color="SeaGreen](.landscape/portrait).<n>[/color]
<moviename>.movie.banner(.landscape/portrait).<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.logo.<n>

I think it should be <moviename>.movie.fanart.(landscape/portrait).<n>

Note the dot has moved outside the brackets to the left, but is still optional OR add dots to all choices eg. (.portrait/.landscape) but i think the first way is clearer.

[AnalogKid]

The wiki is looking gooooood. Very easy to read and navigate.

just one tiny (and probably unimportant thing)

the . (dot) is missing in some of the options (or in the wrong place), assuming () means available choices, and green is optional.

<moviename>.movie.fanart(.landscape/portrait).<n>
<moviename>.movie.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<moviename>.movie.poster[color="SeaGreen](.landscape/portrait).<n>[/color]
<moviename>.movie.banner(.landscape/portrait).<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.logo.<n>

I think it should be <moviename>.movie.fanart.(landscape/portrait).<n>

Note the dot has moved outside the brackets to the left, but is still optional OR add dots to all choices eg. (.portrait/.landscape) but i think the first way is clearer.

I'll fix that up asap!