[Milhouse]

Thanks for the zip.

I still think it's a memory issue.

Running texturecache.py remotely, for just "nc movies", I can see over 80MB of RAM being consumed on the Pi, which is the memory being used by XBMC just to query and then serialise the JSON data (media libary and texture db). Obviously, running texturecache,py on the Pi itself would at least double this RAM requirement.

I'm not sure of your precise configuration, but you obviously have logging enabled, and I'll take a guess that you also have cache.castthumb enabled.

Disabling the logfile (@logfile=) will prevent the creation of one or two large buffers and may leave enough RAM for the script to load everything it needs. "nc movies" worked here without logging, but failed to complete with logging enabled.

Also, caching cast artwork massively increases the number of items to be loaded and processed. Although it's only 1279 movies, you have a total of 26,695 cast thumbnails out of a total of 63,697 cast members, all of which need to be loaded into memory then processed (although all of the cast members without thumbnails will be discarded, they still need to be loaded first). Disabling cast caching (@cache.castthumb=no) will, I'm sure, eliminate memory issues although it does of course mean you will not be pre-loading the cache with cast thumbnails.

I think there will be instances when it's just not going to be practical to run texturecache.py directly on a memory limited device, in which case running texturecache.py remotely is probably the best option, particularly if you want to cache cast members.

I'll give some thought to how the memory overhead could be reduced, but other than executing multiple queries and discarding as much as possible between queries, nothing is leaping out at me. Unfortunately there's no way to query XBMC for only those cast members with thumbnails... now that would be nice.