XBMC Community Forum
FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? - Printable Version

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

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23


- digitalhigh - 2009-07-04 05:08

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

Aight...my end is there. If anybody else familiar with the skinning engine could review this and offer a critique, it would be much appreciated.


- MaxNL - 2009-07-04 10:55

digitalhigh Wrote:http://xbmc-media-art-proposal.wikidot.com/skin-considerations

Aight...my end is there. If anybody else familiar with the skinning engine could review this and offer a critique, it would be much appreciated.

@digitalhigh:
It is not clear to me that part of your skin suggestions:

ListItem.Image(thumb,n,orientation)

I know that there's currently a listitem.thumb property, and that every skin in existence probably uses it. But I just figured that if we're aiming for consistency, maybe this should be transitioned to, and start depreciating infolabels like Listitem.Thumb/Listitem.Icon/Listitem.Property(Fanart_Image).

This would be the "cover" or "poster" or "banner", depending on the media being used. As with fanart, n could be used to have multiple images available, and the orientation would determine whether a banner or poster is displayed.

Ex: Listitem.Image(thumb,01,landscape) - would display the first banner.
ListItem.Image(thumb,03,portrait) -would display the third poster.
ListItem.Image(thumb) - whatever people decide on. I'm just trying to get a rough idea going.

I mean, how is it going to decide between banner poster or thumb?

Regards
Max


- xexe - 2009-07-04 13:08

I had a quick pass at the spec.

HasBeenPlayed
'Watched', but a more generic term to cover Audio and even Images

is problematic since XBMC is multi-user and this item does not cater for that. I cannot suggest a solution for this yet as there is no easy way to know which user the tag is for if you cater for art in several lcoations.

Also can i throw something in for consideration.

Instead of fanart, cover etc etc why not just list the resolution. From the resolution you know what the art is and you have the added advantage of having that info available via the filename rather than reading file contents.


- Gangsta - 2009-07-04 16:13

could the skinning engine not just accept

ListItem.Image(".fanart<n>.portrait")

to maintain the design breif of being extensible. if you use the ListItem.Image(thumb,n,orientation) style of it, won't that require coding to support any new artwork types?


- AnalogKid - 2009-07-04 16:36

xexe Wrote:I had a quick pass at the spec.

HasBeenPlayed
'Watched', but a more generic term to cover Audio and even Images

is problematic since XBMC is multi-user and this item does not cater for that. I cannot suggest a solution for this yet as there is no easy way to know which user the tag is for if you cater for art in several lcoations.

Also can i throw something in for consideration.

Instead of fanart, cover etc etc why not just list the resolution. From the resolution you know what the art is and you have the added advantage of having that info available via the filename rather than reading file contents.

Hasbeenplayed isn't a flag to keep a record of a movie being played or not, it's the IMAGE displayed if a movie has been played (quite a different thing). XBMC handles the logic behind knowing if a movie is played or not. This is simply the <true> or <false> images that are displayed depending on the condition.

For the resolution idea.... loads of issues with that:

a) The resolution will NOT tell you what the art is. You can have a poster and a cover at the same resolution, how do you know which is which?

b) When a skin wants an image, it usually wants a type of image more than a resolution... how would a skin ask for a specific resolution? or are you suggesting it asks for portrait, but that XBMC 'deduces' the orientation from the resolution?
I just don't think it's the right way to go, since there are so many subtle variations in resolutions it becomes harder to read, and besides... this can still be read if it had to be (just not from the filename). Using the resolution would work, absolutely it would, but it will slow down XBMC scanning (since XBMC will have to get the resolution then do a little math to figure the orientation).


- xexe - 2009-07-04 16:50

Ahh that makes alot more sense. you should update the wiki to refelct that as it isnt obvious what hasbeen played means

Using TVDB artwork as a reference each different type has a different resolution. Maybe that cant be relied on though I am in two minds but right now unless I am missing something it would work.

I am still concerned about the multiuser thing though as over time XBMC will evolve to be more multiuser centric not less and right now we are designing the next generation of naming that is not compatible with that philosophy.


- AnalogKid - 2009-07-04 16:51

Gangsta Wrote:could the skinning engine not just accept

ListItem.Image(".fanart<n>.portrait")

to maintain the design breif of being extensible. if you use the ListItem.Image(thumb,n,orientation) style of it, won't that require coding to support any new artwork types?

I'm not sure if thumb really means THUMB as we know it today, I think it means this...


ListItem.Image(imagetype, orientation, index)
imagetype is the extensible type (fanart, cover.front etc etc), index would be the image index required.


- AnalogKid - 2009-07-04 17:03

xexe Wrote:Ahh that makes alot more sense. you should update the wiki to refelct that as it isnt obvious what hasbeen played means

Using TVDB artwork as a reference each different type has a different resolution. Maybe that cant be relied on though I am in two minds but right now unless I am missing something it would work.

I am still concerned about the multiuser thing though as over time XBMC will evolve to be more multiuser centric not less and right now we are designing the next generation of naming that is not compatible with that philosophy.

Multiuser will never be an issue...
It's no different than the media files and artwork today. If you have a movie.avi and a movie.jpg, all users get the same art. They can override that art by choosing a new image, and in the same way, a user can override the art in our schema. Our schema is just the same as 'movie.jpg' solution today, but with more flexibity. It definitely doesn't make multiuser any different.
However, IF the user actually stores their art in one big flat folder, it can even improve user profiles (in theory), with every user having their own artwork folder (if they wanted to). But this is totally down to XBMC to manage.


- digitalhigh - 2009-07-04 17:07

MaxNL Wrote:@digitalhigh:
It is not clear to me that part of your skin suggestions:

ListItem.Image(thumb,n,orientation)

I know that there's currently a listitem.thumb property, and that every skin in existence probably uses it. But I just figured that if we're aiming for consistency, maybe this should be transitioned to, and start depreciating infolabels like Listitem.Thumb/Listitem.Icon/Listitem.Property(Fanart_Image).

This would be the "cover" or "poster" or "banner", depending on the media being used. As with fanart, n could be used to have multiple images available, and the orientation would determine whether a banner or poster is displayed.

Ex: Listitem.Image(thumb,01,landscape) - would display the first banner.
ListItem.Image(thumb,03,portrait) -would display the third poster.
ListItem.Image(thumb) - whatever people decide on. I'm just trying to get a rough idea going.

I mean, how is it going to decide between banner poster or thumb?

Regards
Max

You differentiate between banner or poster by using the "orientation" param. Landscape would use the banner image, portrait would use the poster.

Gangsta Wrote:could the skinning engine not just accept

ListItem.Image(".fanart<n>.portrait")

to maintain the design breif of being extensible. if you use the ListItem.Image(thumb,n,orientation) style of it, won't that require coding to support any new artwork types?

Either way, this is going to require coding to support new artwork types.

The reason I opted to go with the format of

Listitem.Image(fanart,n,portrait)

over

Listitem.Image(".fanart<n>.portrait")

is simply due to the current setup of XBMC infolabels...and because then the defaults would use less code. Also, other infolabels are done up already by just being comma-separated.

Basically, I envisioned it as being Listitem.Image(fanart) would just pull the regular fanart image similar to the way it's done now. You don't have to include the parameters for number or orientation.

Make it Listitem.Image(fanart,03), and it would grab the third fanart image...etc...

Does that make sense?


- xexe - 2009-07-04 17:10

AnalogKid Wrote:Multiuser will never be an issue...
It's no different than the media files and artwork today.

All that really says is "the current way is lacking". This we know.

AnalogKid Wrote:Multiuser will never be an issue...
...If you have a movie.avi and a movie.jpg, all users get the same art. They can override that art by choosing a new image, and in the same way, a user can override the art in our schema.

So user 1 can use the new scheme and user 2 has to rely on XBMC manual choices via the GUI. Not especially flexible when you get to a family of 4 or a dorm of 10.

AnalogKid Wrote:Multiuser will never be an issue...
...
However, IF the user actually stores their art in one big flat folder, it can even improve user profiles (in theory), with every user having their own artwork folder (if they wanted to). But this is totally down to XBMC to manage.

Agreed but this fundamentally breaks one key design goal of "3) Is placeable ANYWHERE in the filesystem" and as such is not appropriate.

Trying to dea lwith this might be too much for this project but if a solution can be derived that is logical and easy to implement you have one more reason why the devs might implement it.

I am out on the town tonight meaing i will have some time to ponder this over. Dont get to into this until I have had time to mul over where I am going with this whole area