[Milhouse]

So if I don't make my artwork 'local' does that mean that my database is fetching information 'remotely', albeit in a cached format that would slow down scrolling through my library (as an example)?

Almost certainly, yes. You can view your movie metadata with "texturecache.py jd movies [moviename]" and if the artwork (poster, fanart, etc.) urls are http-based then your artwork is remote.

Once the artwork is cached there's not going to be any performance difference between remote and local artwork.

The main advantage of local artwork is that if you re-scan your library in future, you get the same artwork you had before - when using remote artwork it's a lottery what artwork the scraper will find. Also, if you decide to recache a movie, the remote artwork might have moved or been re-named since it was scraped, and it won't be possible to re-cache the artwork. This is a particular issue while using a shared MySQL library as new clients cannot cache and display the artwork that was scraped months or even years ago.

To take it back a step and I apologise for the layman undertones but I just hate not understanding things.. I have my pi running Kodi on 192.168.1.4 that is accessing my NAS via NFS on 192.168.1.7. Via Putty I can run your programs in W10 (or alternatively linux based systems) without issues and can edit files via Filezilla or the like. So, when I run the below script for movies as an example is it fetching the movie data again and linking it between pathways? Or is it providing a link between the cached movie database already on the pi to the NAS for local storage? The latter doesn't seem to be right...

./texturecache.py jd movies | ./mklocal.py --local /freenas/media --prefix nfs://192.168.1.7/share/Videos --artwork fanart poster clearlogo clearart --output fixup.dat

Thanks in advance.

The script is taking the artwork urls defined in the library for each movie, and converting the artwork paths from the nfs:// format used by Kodi into a format that can be accessed by the script running on the current OS - in the case of a W10 machine your --local path would have to be something like D:/Videos (or whatever drive mapping you use to access the NFS Videos share), so that "nfs://192.168.1.7/share/Videos/Movies/Avatar-poster.jpg" is mapped to "D:/Videos/Movies/Avatar-poster.jpg".

Don't worry if you don't have any local posters yet - the script will download your remote artwork and create the files for you (alternatively, it will identify your local artwork and add those to your library if they are not already present - it can do this for any type of artwork so is good for adding manually downloaded logos and clearart etc.). The script will construct the artwork file names based on the movie file name, so as long as you have "nfs://192.168.1.7/share/Videos/Movies/Avatar.mkv" (or whatever) then the script knows where it needs to put or find your artwork (alongside your movie file).

If you have remote artwork then it will download that artwork and store it alongside the movie file using the moviename-poster.jpg naming format, and then at the end it will output (in fixup.dat) the changes needed to update your library so that your remote artwork urls are replaced with your new local artwork urls. You apply the changes using "cat fixup.dat | texturecache.py set", and then you can cache your new local artwork in the normal way (ie. "texturecache.py c movies", etc.)

If you're not sure about running the mklocal.py script, then include the "--read-only --dryrun" options so that it won't create or change any of your existing files.