xbmc/xbmc — comment on commit dbf85d5dd420517fb9e20aa0d619e7d4f4624734
File:  line 0
By jmarshallnz:

Ok, first the CThumbnailCache::GetFanart() - my guess is this happens to movies all in the same folder that hasn't been scanned, and is because the item has it's watched state set, which creates the videoinfotag, but the videoinfotag doesn't have the path information? We don't want to just remove the path.IsEmpty() line as that's handling things like categories in the library (for which obviously there is no fanart). We could, however, test whether the infotag is "empty" or not (this is true if title, path and file are all empty) and if so, don't do that first block.

If the user hasn't scanned and all they have is -fanart.jpg, then I think we've never shown anything for the folder. If they have scanned, then we should show the fanart regardless, as I believe it should be cached on the movie item's path, which should be available to us in the infotag object, thus the checks in CThumbnailCache::GetFanart() should succeed.

Thus, I think the only case that fanart won't show is unscanned movies_as_folders that contain -fanart.jpg OR unscanned movies_as_files that contain fanart and who's watched status is set (not sure it actually needs to be watched or not).

SideNote: IMO if movies are folders then the ONLY thing we should support is fanart.jpg. If movies are not in folders than -fanart.jpg is fine. Reason is that we want to be able to test _quickly_ (rather than retrieving the directory as is done currently in GetLocalFanart) for fanart files, and having to fetch the directory so that we grep for -fanart.jpg is silly. Obviously this has a slight problem in that XBMC doesn't export stuff in this form.