(2015-05-17, 17:19)Martijn Wrote: [ -> ]from what i can recall is that you set it for the entire plugin. If you put this in the beginning of your plugin the xbmcplugin.setContent() will always be called prior to entering any level of the plugin.
Should you have a variety content you need to set for that level (don't shoot me if i'm wrong here 
)
That's correct, you can set it for different directory types at plugin entry. The question I'm asking is when I have a mixed directory (let's say some are playable items and some are next level directory items in the same directory) is there a way to set content for the individual listitem vs. the whole directory?
The most common example is when I have list of TV episodes (which should be content type= "episodes") and I need to put a "Next Page" listitem at the bottom of the list (which I guess should be content type = "files" as the image is an icon). There are more complex examples where some websites mix movies and tv episodes in the same directory. I really don't want to have to figure out and create separate directories for content type if that's not the way it's presented on the website - I'll most probably always get it wrong like in snagfilms.
content is set on the container, not on the individual listitems.
i would (edit
not worry to much about the 'next page' or 'up' entries ;-)
(2015-05-17, 18:49)ronie Wrote: [ -> ]content is set on the container, not on the individual listitems.
i would (editnot worry to much about the 'next page' or 'up' entries ;-)
Thanks - good to know. Does anyone know the desired resolutions for the different content types?
I'm pretty sure content type = "files" = icon = 256x256.
What is the correct poster size?
Does it matter what the thumbnail size is ?
Thanks.
They're different for every skin.
(2015-05-17, 18:59)learningit Wrote: [ -> ]What is the correct poster size?
Does it matter what the thumbnail size is ?
Like Hitcher said, its going to change depending on the skin and what view is used.
More problematic is the multiple specifications for movie poster aspect ratios.
themoviedb.org uses a 1:1.5 ratio -- i.e. 1000x1500
fanart.tv uses 1000x1426
another spec was 680x1000 (which is approx 1000x1470)
I use themoviedb specs in all my skins because 1:1.5 is the easiest to work with and lots of users scrape artwork from themoviedb
For fanart/thumb type views I use 16:9
We seem to have a standard definition for an icon size (256x256), fanart (1280x720 or 1920x1080) and a thumbnail having a 16:9 aspect ratio for skins/addons.
It seems we need to define a standard poster size and/or aspect ratio.
I'm thinking that it should become the addon's responsibility to provide provide the best resolution image it can in the correct aspect ratio and standard size for a given defined image (content) type. This may mean using something like PIL to take a smaller, oddly sized image provided by a website and merge it on a correctly sized background to provide the image to the skin. This would allow the addon to load an appropriate image from the source website and transform it into a standard usable image for a skin. If a skin needs to change the size or aspect ratio from the standard definition it becomes the skin's problem to re-size.
I think something like this will work whether the images come from a source website or a metadata source for an addon.
Another way to do this may be to have the skin provide standard sized background images for each content type and have the addon either mount an appropriately sized image on the background image or pass the image to the skin to mount. This may produce a better looking result for some skins depending on the background image they provide.
So,
1) Is it possible to define an image standard for each content view?
2) is it possible to provide PIL (Python Imaging Library) as a standard library for addons if the above makes sense?
3) is there a way to pass standard background images for a content type from a skin to an addon?
Please don't something hackish
We have just to use this correctly as addon-devs and everything is fine. Concfluence is doing a great job with this information.
http://mirrors.kodi.tv/docs/python-docs/...tem-setArt
There is no image standard or size...only if you/we as addon-devs provide them with the addon. But every external (web) image is out of hand for us. I've so many different sizes...even YouTube has no fanart in 1280x720 or 1920x1080....RedBull even returns 4000xXXXX images.
I vote against PIL (sorry no offense @learningit) - but the addon shouldn't process the image. Take YouTube for example. I have (worst case) 50 different fanarts (for each channel) and 50 different thumbs. To process them with PIL I would have to resize/crop 100 images...do this on a slow RasPi or other Atom-Machine and the user won't have a nice user experience.
We as addon devs. have to set the content type correctly (I do it since my first addon, because without it most skins show not a single additional information for video - how should they)
http://mirrors.kodi.tv/docs/python-docs/...setContent
...and (if available) set all possible images
http://mirrors.kodi.tv/docs/python-docs/...tem-setArt
as I said....concluence is doing it right with this informations.
I hope I offended no one with my statement
just want to be constructive, use things which are already exists - and I hate hackish solutions
I agree with 99% of what you're saying above.
The issue is that even setting all the content types correctly does not fix the problem completely.
It is compounded by skins having their own interpretation of how each image type is sized or it's aspect characteristics. Getting all skins to use the a standard size image definition does not solve the problem completely.
The addon passing the skin images of odd sizes is really the issue.
The conversation is one about how to address that issue.
I am absolutely NOT enthralled with using a solution at addon level to resize images. But I do believe that the addon developer is the authority about what size images can be provided by a website and how best to present those images with standard characteristics. In some cases this may mean that an addon developer needs to do nothing because the images he has are a reasonable fit. In other cases it becomes necessary to process the image to provide something that the skin can use correctly. In an effort to avoid "hackish" solutions, it would seem reasonable to provide the addon dev with a standard set of tools to achieve that.
I was driven by something more basic and to your point about not repeatedly processing images to propose that the addon be responsible for the resizing: I was guessing that the Kodi thumbnail cache is storing the image as passed from the addon and not the skin.
If resizing is needed at any level to fix the problem, the issue of slow or less powerful platforms still exists.
You are probably correct in saying that the resizing shouldn't be done by the addon, but there do seem to be times when it may be appropriate.
BTW - my 1% deviation is that I find it amusing that an addon dev who hates "hackish" things would think that addon development is anything else but - isn't that what makes it fun?
(2015-05-18, 14:06)learningit Wrote: [ -> ]I agree with 99% of what you're saying above.
The issue is that even setting all the content types correctly does not fix the problem completely.
I agree with you - this will not completely resolve the issue
(2015-05-18, 14:06)learningit Wrote: [ -> ]It is compounded by skins having their own interpretation of how each image type is sized or it's aspect characteristics. Getting all skins to use the a standard size image definition does not solve the problem completely.
The addon passing the skin images of odd sizes is really the issue.
The conversation is one about how to address that issue.
I am absolutely NOT enthralled with using a solution at addon level to resize images. But I do believe that the addon developer is the authority about what size images can be provided by a website and how best to present those images with standard characteristics. In some cases this may mean that an addon developer needs to do nothing because the images he has are a reasonable fit. In other cases it becomes necessary to process the image to provide something that the skin can use correctly. In an effort to avoid "hackish" solutions, it would seem reasonable to provide the addon dev with a standard set of tools to achieve that.
I was driven by something more basic and to your point about not repeatedly processing images to propose that the addon be responsible for the resizing: I was guessing that the Kodi thumbnail cache is storing the image as passed from the addon and not the skin.
If resizing is needed at any level to fix the problem, the issue of slow or less powerful platforms still exists.
You are probably correct in saying that the resizing shouldn't be done by the addon, but there do seem to be times when it may be appropriate.
Well, I agree
we should develop an addon together
I think a least some guidelines wouldn't hurt...what is for example the ratio of a banner (maybe the max sizes w/h)...or have I overseen this information? I think the addon dev. has the responsibility to provide as much as possible of images....and maybe the last resort is to resize an image on addon level (I hope not, but there may be exceptions
)
(2015-05-18, 14:06)learningit Wrote: [ -> ]BTW - my 1% deviation is that I find it amusing that an addon dev who hates "hackish" things would think that addon development is anything else but - isn't that what makes it fun?
My work forbids "hackish" in a way
I work on sensible processes...if something can't be maintained fast (readability of code), isn't test driven development or dirty code -> I wouldn't have the job and responsibility I have now.
I agree of "hackish" in terms of interpreting data or parsing/scrape a web-page
but anything else around it should be clean (as much as possible).
It's not the size of images that's the problem; it's their aspect ratios. Movie and TV show views will use a portrait aspect ratio, episode views will use landscape, and everything else will be square.
(2015-05-18, 17:36)Hitcher Wrote: [ -> ]It's not the size of images that's the problem; it's their aspect ratios. Movie and TV show views will use a portrait aspect ratio, episode views will use landscape, and everything else will be square.
Agreed
- this would work for me
I would say this sounds like some simple guideline
I like! How we proceed from here?
Just set the content based on the aspect ratio of the images used rather than the actual content type.
So if your addon supplies movies but they use landscape style images set the content to episodes.
Hope that makes sense.
(2015-05-18, 17:50)Hitcher Wrote: [ -> ]Just set the content based on the aspect ratio of the images used rather than the actual content type.
So if your addon supplies movies but they use landscape style images set the content to episodes.
Hope that makes sense.
no, that´s not a good way to solve it. In that case the plugin should set the content to movies and use Art(landscape) (and perhaps Art(thumb) as a fallback)
(2015-05-18, 17:50)Hitcher Wrote: [ -> ]Just set the content based on the aspect ratio of the images used rather than the actual content type.
So if your addon supplies movies but they use landscape style images set the content to episodes.
Hope that makes sense.
Not quite...Movies should show different informations then episodes for TV shows. Compared on the behavior of Confluence...the information are quite different for movies and episodes. The skin behaves different - the navigation in the information dialog is different.
I would put all images I can get via the setArt method....for example: for YouTube I get three different types of images, the fanart (landscape), a banner and a thumb (square). But to return to your guide line...I would see to it to provide for the videos (episodes) landscape images. For everything else (even the channels) I don't set a content and provide only the square thumbs (Like your example).
Video (episodes) = Landscape
Navigation and Channels (None) = Square
Sorry, didn't realise addons could also set the art type.
EDIT: Just a shame we don't have ListItem.Art(square) and I think everything would be covered.