2014-05-05, 18:22
Thanks for the very detailed logs, much appreciated! 
First of all, this is my understanding of how extrafanart/extrathumbs works from the XBMC perspective.
extrathumbs/extrafanart are not present in the media library (this is why they're not shown with "jd movies") so what a skin has to do at run time is determine if you have extrathumbs/extrafanart artwork by checking the physical source to see if there is a directory called extrathumbs or extrafanart. If such a directory exists, the skin will then load the thumbs/fanart artwork using whatever art files it finds in your extrathumbs/extrafanart folders.
In your case, although the artwork is in the cache (when the disk is online), when you later view the movie while the disk is offline the skin will not be able to determine if you have an extrathumbs/extrafanart directory, so it will instead display placeholder artwork in any view that requires extrathumbs/extrafanart. I wouldn't be surprised if the skin generates a couple of "directory not found" type errors in the xbmc.log for each movie that is located on a sources that is offline.
Connect the drive/source again, and now the skin will "know" that you have the required directories so it will be able to load the relevant extrathumbs/extrafanart artwork.
In a nutshell, extrathumbs/extrafanart is only going to work while the source is online. This is because the media library knows nothing about extrathumbs/extrafanart - it's a skin-specific solution which requires physical access to the source at the time the movie is viewed.
Preloading the cache with the extrathumbs/extrafanart artwork avoids the whole caching-as-you-browse process but won't allow such artwork to be displayed while the source is offline because the skin has no way of determining that this extra artwork actually exists unless it can access the source.
As for the double caching of the extrathumbs/extrafanart - that looks like a bug (no pun intended!) in the skin.
Note how texturecache.py has cached the extrathumbs (first 4 rows) using a perfectly valid url, but the skin has cached the same artwork using a different (malformed) url:
The skin is constructing the url for the extrathumbs artwork using a forward slash when appending the filename to the path and not a backward slash which would be normal (and correct) when using a Windows local source. When XBMC attempts to load the artwork using the malformed url it first looks in the cache and doesn't find anything for the url so the artwork is cached a second time using the malformed url. Subsequent views will find and use the cached artwork corresponding to the malformed urls.
XBMC will tolerate this kind of error in a url (ie. it will find and load the artwork from the source) but given the way the cache works, matching on exact urls, it does mean artwork can be cached multiple times if the url varies in any way. You might now use another skin that doesn't contain this forward-slash error, and this other skin will correctly use the artwork cached by texturecache.py, ignoring the same artwork cached using the malformed url, resulting in a excessive cache "bloat". Pruning your cache will also remove these malformed urls as they won't be recognised and retained.
My advice would be to contact the skin author and highlight the error as it means that anyone switching to this skin will find their cache bloated with double the extrathumbs artwork as the skin won't be able to make use of cached extrathumbs already loaded by other skins (or by texturecache.py). Out of interest, which skin is this?
First of all, this is my understanding of how extrafanart/extrathumbs works from the XBMC perspective.
extrathumbs/extrafanart are not present in the media library (this is why they're not shown with "jd movies") so what a skin has to do at run time is determine if you have extrathumbs/extrafanart artwork by checking the physical source to see if there is a directory called extrathumbs or extrafanart. If such a directory exists, the skin will then load the thumbs/fanart artwork using whatever art files it finds in your extrathumbs/extrafanart folders.
In your case, although the artwork is in the cache (when the disk is online), when you later view the movie while the disk is offline the skin will not be able to determine if you have an extrathumbs/extrafanart directory, so it will instead display placeholder artwork in any view that requires extrathumbs/extrafanart. I wouldn't be surprised if the skin generates a couple of "directory not found" type errors in the xbmc.log for each movie that is located on a sources that is offline.
Connect the drive/source again, and now the skin will "know" that you have the required directories so it will be able to load the relevant extrathumbs/extrafanart artwork.
In a nutshell, extrathumbs/extrafanart is only going to work while the source is online. This is because the media library knows nothing about extrathumbs/extrafanart - it's a skin-specific solution which requires physical access to the source at the time the movie is viewed.
Preloading the cache with the extrathumbs/extrafanart artwork avoids the whole caching-as-you-browse process but won't allow such artwork to be displayed while the source is offline because the skin has no way of determining that this extra artwork actually exists unless it can access the source.
As for the double caching of the extrathumbs/extrafanart - that looks like a bug (no pun intended!) in the skin.
Note how texturecache.py has cached the extrathumbs (first 4 rows) using a perfectly valid url, but the skin has cached the same artwork using a different (malformed) url:
Code:
070116|a/aa82ea12.jpg|0439|0780|0001|2014-05-05 09:15:28|2014-05-05 16:15:28|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs\thumb1.jpg
070117|7/71954285.jpg|0439|0780|0001|2014-05-05 09:15:28|2014-05-05 16:15:28|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs\thumb2.jpg
070118|3/38982508.jpg|0439|0780|0001|2014-05-05 09:15:28|2014-05-05 16:15:28|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs\thumb3.jpg
070120|c/c37b0e1c.jpg|0439|0780|0001|2014-05-05 09:15:30|2014-05-05 16:15:29|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs\thumb4.jpg
070123|c/c46211dd.jpg|0439|0780|0002|2014-05-05 09:36:19|2014-05-05 16:34:36|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs/thumb1.jpg
070124|5/5678dec7.jpg|0439|0780|0002|2014-05-05 09:36:19|2014-05-05 16:34:36|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs/thumb3.jpg
070125|a/ad9bf5d3.jpg|0439|0780|0002|2014-05-05 09:36:19|2014-05-05 16:34:37|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs/thumb4.jpg
070126|1/1f75b94a.jpg|0439|0780|0002|2014-05-05 09:36:19|2014-05-05 16:34:37|G:\Hard Drive 0\Movies - Kids\A Bugs Life [1998]\extrathumbs/thumb2.jpgThe skin is constructing the url for the extrathumbs artwork using a forward slash when appending the filename to the path and not a backward slash which would be normal (and correct) when using a Windows local source. When XBMC attempts to load the artwork using the malformed url it first looks in the cache and doesn't find anything for the url so the artwork is cached a second time using the malformed url. Subsequent views will find and use the cached artwork corresponding to the malformed urls.
XBMC will tolerate this kind of error in a url (ie. it will find and load the artwork from the source) but given the way the cache works, matching on exact urls, it does mean artwork can be cached multiple times if the url varies in any way. You might now use another skin that doesn't contain this forward-slash error, and this other skin will correctly use the artwork cached by texturecache.py, ignoring the same artwork cached using the malformed url, resulting in a excessive cache "bloat". Pruning your cache will also remove these malformed urls as they won't be recognised and retained.
My advice would be to contact the skin author and highlight the error as it means that anyone switching to this skin will find their cache bloated with double the extrathumbs artwork as the skin won't be able to make use of cached extrathumbs already loaded by other skins (or by texturecache.py). Out of interest, which skin is this?
