2014-01-03, 03:50
(2014-01-03, 03:41)MilhouseVH Wrote:(2014-01-03, 03:15)shadrach47 Wrote: Maybe I'm confused and doing all this for nothing, but technically no art is on my computer.
LOL yes, that could be a problem...
(2014-01-03, 03:15)shadrach47 Wrote: I access it all from a mapped network drive. Could the issue be that it's just pulling the actual location and not the mapped one I set up? I also have a symlink for it in C:\ (was trying it for something else), but it probably would do the same thing.
The computer you are running the mklocal.py script on must to be able to access (read) the artwork, that's what the --local path is for. Just specify a path for --local that allows the computer to access the artwork.
Your C:\ symlink may work, or a UNC, or simply a mapped drive - anything that can access the network location should work.
(2014-01-03, 03:15)shadrach47 Wrote: Maybe I'm not supposed to run mklocal, but I thought you need to if you need to fix wrong cache itemsThat's one use for it, to correct artwork. Or to convert remote artwork to local (in this case, mklocal.py will download the original artwork and write it into your local media folder, outputting the corrections that need to be applied to your media library). Or to associate non-standard already existing local artwork (clearlogo, clearart, discart etc.) with existing movies or tvshows (although AD will also perform this function, but not if you are using movie name prefixes).
If you just want to simply pre-load the cache on a client you don't need mklocal.py you only need texturecache.py.
mklocal.py works in conjunction with texturecache.py and is really intended to help quickly create or load non-standard artwork (ie. those artwork items not supported by the standard scrapers).
(2014-01-03, 03:15)shadrach47 Wrote: basically instead of re-adding the library to the db.It's not going to create movies in the library if they don't exist, it's only going to associate artwork with existing movies. In that sense it's just replacing one of many addons that do that kind of job.
Obviously it's up to you if you want to continue down the mklocal.py route, but I should point out that you are trying to process an artwork type called "disc" when it should be called "discart" (which maps to files using the suffix disc). You can specify this as discart:disc (ie. artwork-type:filename-suffix) when specifying artwork, however the version of mklocal.py I just pushed (2 minutes ago) to github will now handle this automatically so just specify "--artwork discart" rather than "--artwork discart:disc".
It was able to work with the symlink not sure why the mapped drive didn't. I was running it to fix wrong artwork in my db and also to add logo and discart to it instead of AD. Thanks for the tip on the discart,I was trying to see what the discart was supposed to be named since disc didnt seem right if logo was clearlogo. Thanks for all your help, awesome utility