2014-10-26, 10:20
Won't be able to test before long time as changes are major on client side 
But any web interface dev could test and see big improvement
But any web interface dev could test and see big improvement
2014-11-28, 09:45
I'm also really interested in retrieving resized images on the fly through the rpc api. I have together with the designer Joost developed the iPad app 'MediaPortal iViewer' (MPiV) https://plus.google.com/communities/1108...7642540096
Today the app MPiV only support MediaPortal using MPExtended( http://www.mpextended.com/ ) but I keep checking if the Kodi rpc has improved regarding the resized images since adding support for Kodi in MPiV will not happen without this feature. iViewer can resize images on the fly on the client side but scrolling of lists that contain the resized images are very choppy since the images are resized first when they are displayed. This will be the case for all cases when resizing is needed so having a couple of sizes to choose from on the server side will not help, exact pixel size is needed. iViewer also caches images on the client side but I really prefer to have them cached at the server side as well.
MPExtended handle resizing of images on the server side and simply keep the resized images. I have never heard of complaints of that the cache require too much disk space, although the service require Windows where one most often has more available disk space. But I would also assume that the low power hardware (used for Kodi) also has too little power for transcoding images/video as well so one would probably not use these features one them anyway.
The MPExt. service also handle transcoding of video, music and live tv. Also extracting still pictures from video is possible. The main thing I miss is the Kodi support. This can either be achieved by adding support of the Kodi Video/Music/Series databases to MPExtended. Or using the Kodi rpc.
So please consider adding support for resizing images on the fly and simply keep the cached images on disk. Add a user option for how much disk space the cache is allowed to use.
Today the app MPiV only support MediaPortal using MPExtended( http://www.mpextended.com/ ) but I keep checking if the Kodi rpc has improved regarding the resized images since adding support for Kodi in MPiV will not happen without this feature. iViewer can resize images on the fly on the client side but scrolling of lists that contain the resized images are very choppy since the images are resized first when they are displayed. This will be the case for all cases when resizing is needed so having a couple of sizes to choose from on the server side will not help, exact pixel size is needed. iViewer also caches images on the client side but I really prefer to have them cached at the server side as well.
MPExtended handle resizing of images on the server side and simply keep the resized images. I have never heard of complaints of that the cache require too much disk space, although the service require Windows where one most often has more available disk space. But I would also assume that the low power hardware (used for Kodi) also has too little power for transcoding images/video as well so one would probably not use these features one them anyway.
The MPExt. service also handle transcoding of video, music and live tv. Also extracting still pictures from video is possible. The main thing I miss is the Kodi support. This can either be achieved by adding support of the Kodi Video/Music/Series databases to MPExtended. Or using the Kodi rpc.
So please consider adding support for resizing images on the fly and simply keep the cached images on disk. Add a user option for how much disk space the cache is allowed to use.
2014-11-28, 16:01
In order to tackle the hardware problem, would that be possible to create a plug-in doing those,a nd maybe provide it in the stock version, but in a "disabled" state? Just asking of the feasability, as I never tried to program a plug-in there...
So it would get down to the user to enable it if its hardware has enough "power" to manage it.
I also think a manageable cache size would be appreciated.
I don't see how you would retrieve them through JSON.... you mean the actual binary? I think it would be more casual though HTTP requests as requested earlier, and it would also be far more easy to manage the cache on the server-side though HTTP headers...
So it would get down to the user to enable it if its hardware has enough "power" to manage it.
I also think a manageable cache size would be appreciated.
(2014-11-28, 09:45)johanj Wrote: I'm also really interested in retrieving resized images on the fly through the rpc api
I don't see how you would retrieve them through JSON.... you mean the actual binary? I think it would be more casual though HTTP requests as requested earlier, and it would also be far more easy to manage the cache on the server-side though HTTP headers...
2014-12-03, 13:53
Yes, I meant retrieving the images through http and no rpc. Only get the urls of the images through rpc.
I have implemented support for Squeezeboxes earlier and that service can also resize images on the fly and their service can also run on weak hardware.
Rigth now I will add support for MediaBrowser 3 in our app instead of XBMC. Their api has also resizing of images and support streaming/transcoding. Lets hope that the resizing feature gets added to Kodi at some point.
I have implemented support for Squeezeboxes earlier and that service can also resize images on the fly and their service can also run on weak hardware.
Rigth now I will add support for MediaBrowser 3 in our app instead of XBMC. Their api has also resizing of images and support streaming/transcoding. Lets hope that the resizing feature gets added to Kodi at some point.
