This moves video art to the texture cache.
We store all video art in the video library (for items in the library) in the new art table.
There's backward compat in the thumbloader to find the image. Obviously we may get this wrong in the case where the user has changed the thumb or fanart to something other than the local image or the first scraped image, but that's what this is here to solve :)
It'd be useful to get #918 in first I think.
@Montellese: the last commit uses cached paths for JSON-RPC, as I believe this is required for back-compat. Hopefully we can redo to something like image:// URLs later on so we don't need the texture cache hits (which are on-thread).
Ok, rebased after several changes required.
@Montellese would appreciate you haven't a look over the json-rpc changes. In particular, there's the potential for the videolibrary update routines to update art now as well.
Would really like this to hit May, as quite a few users (particularly those that use mysql) have been waiting on it, so getting it wider tested as I work on the music thumbs would be useful.
I only looked at the last commit and it looks like that should work for now for JSON-RPC. Didn't give it a spin but will be happy to once this has been merged. As there is no pre-frodo addon repo yet there are no webinterfaces and scripts which use the latest changes in JSON-RPC and we can easily fix a bug or two in case it doesn't work as expected.
IMO we should put together a plan on how to proceed on this image-access for JSON-RPC business as it came up in multiple places now and really needs to be addressed.
Thanks @Montellese - I think the plan would be:
With 1 and 2, images may be accessed the exact same way as is done at the moment (backward compat). This would basically run through the texturecache initially at least (ensuring the image is cached before being returned if it hasn't already been done).
Numbers 3 and 4 could be done independently.
Sounds pretty much like what I had in mind. 1 and 2 should not affect JSON-RPC clients as they usually just take what they get from "thumbnail" and/or "fanart" and throw it at http://url:port/vfs/
From what I understand looking at your "hacks" needed for JSON-RPC those two steps are the most important ones and as they won't break backwards compat I say "go for it" :-)
IIRC there was still some discussion on what extras (resizing/transformation) to add to image:// but I'd say the most important one (at least for JSON-RPC clients) is resizing. Once 3 and 4 (github got you there and changed them to 1 and 2) are done we can consider getting rid of the highly insecure VFS access handler in the webserver (which will break backwards compat to Eden).
We have to plan out the API for images quite well - in particular, we need to ensure that whatever we pass in there can't go through the general VFS to end up being a backdoor to access images that the client should not have access to (or worse).
I'm not sure the best way to do that, but I guess one way is to use some sort of ID for the images instead of the image:// URL. This could just be kept in an in-memory map(id,url) easily enough, but would clients expect it to be persistent information (if so, a db map would be needed).
I think we should first implement step 1 and 2 so that the TextureCache is in full control of image access and caching before we start worrying about how we can securely expose that information to the outside world. With the webserver being implemented in handlers it has become a lot easier to write (and replace) specific handlers. Obviously this won't stop us from doing something stupid though ;-)
An image-based ID sounds good to me. The question will be whether JSON-RPC requests will directly return those IDs or if they return a real or an image://-based path which then needs to be passed to Files.PrepareDownload (which already exists for this purpose so looks like we actually did something right in the past) to retrieve the ID which will allow a client to actually download the image.
IMO if a client decides to persistently store media item information it should also store the images (which will also speed up the responsiveness and load time of the client). All other (state-less) clients like the default webinterface will always ask XBMC for the information whenever it is requested by the user and then use whatever is returned right then. So IMO there would be no need to persist those mappings.
Sounds good. JSON-RPC requests would return IDs rather than real paths/images. Otherwise we'd have to add a bunch of checking to the main image API to make sure that the image they're requesting is "allowed". Much easier to give 'em an id as then XBMC is in control of the URLs they have access to.
Ok, rebased the typos etc. that @cptspiff found and rebased on master following @Montellese changes.
Will look into the season thing over the next few days to see whether it's feasible. Otherwise, please continue review as and when you have time :)
Updated with a seasons table so we have a unique id per season, thus m_type is now one of movie,musicvideo,episode,season,tvshow,actor,artist,director,writer,set.
add seasons table to the video database so we have a unique id per se…
use the unique id for the season in m_iDbId
don't SetCachedVideoThumb after setting the channel icon
move embedded video thumbs to the texture cache
remove CThumbLoader::LoadRemoteThumb() now that the texturecache hand…
…les it anyway
move video (files and embedded) thumbs to the texture cache
size wasn't stored for picture folder thumbs
Add art table to video database
CVideoThumbLoader::GetLocalThumb -> CVideoThumbLoader::FillThumb
CVideoInfoScanner::GetArtwork() needn't download art on thread - cach…
…e them into the texture cache async instead. Further, don't bother setting art if the item already has it.
add m_type attribute to CVideoInfoTag to aid in determining what type…
… of item we have
move GetArtwork() into the start of AddVideo()
add routines to get and set art of items
add set/getartforitem methods to the videodb
add art to the video library during scan
load video database thumbs in the video thumb loader
add backward compatibility to fetch thumbs and fanart for items in th…
…e video library without art assigned
add ability to send additional elements into CVideoInfoTag::Save
move setting of fanart/thumbs to fetch from and update the db
add GetTvShowSeasonArt helper to VideoDatabase
when importing and exporting the video library to a single folder str…
…ucture, there's no point in dumping art. Store the URLs in the xml instead
fetch season thumbs prior to adding tvshow to the db so that season a…
…rt is available
on scan, add actor thumbs to the db
retreive thumb from db when retrieving cast
no need to DeleteThumbForItem() in the videodatabase - the texturecac…
…he knows about them
get rid of unused video thumb functions
setting of season thumbs can now be handled by the database
clear artwork prior to re-fetching info when doing online lookups
Add backward compatibility for actor/season thumb fetching
use the cached version of textures for JSON-RPC
tested, fixed a few minor issues, rebased again. IMO this is now ready to go.
while granted not a thorough review i have read through it and did not spot anything obvious. show it in there. we will have to deal with it no matter;)
Good enough for me :)
ERROR 1170 (42000): BLOB/TEXT column 'media_type' used in key specification without a key length
Installer now checks for Vista or later.