Building Cache - Command Line

[smak]

Is there any way to utilize the API to initiate the building of the cache from a command line script.

I have been experimenting with moving the cache to a RAM Disk with decent results. However, the cache would need to be rebuilt when the computer restarts. It would be nice if I could initialize the RAM Disk and kick off the pre-cache routine.

No, I do not have a fancy fast SSD. That would make things too easy

-smak

[jusjoken]

If you have move the cache...how is gemstone finding it while running? If gemstone can find it then could you not just copy the the ram disk on startup...I am likely missing something here!

k

[Fuzzy]

I think I've gone through just about every iteration of various combinations of RAMDisks, SSD's, and Disk caches, and I've settled on the fact that the single best way to always get the easiest/best performance, while still allowing real-time updates of fanart, is to run a very large Disk Cache (I am currently running FancyCache, 4GB, on each client, and 4GB on the server), on a conventional HDD. This does a wonderful job of keeping everything in memory, and the system really does navigate quickly.

[smak]

Originally Posted by jusjoken

how is gemstone finding it while running?

I am using Windows Junction (link) to redirect the cache directory. Junction is a windows version of doing a symbolic link. Gemstone just writes to the same location and the OS handles the change.

On the extenders I set the cache setting to NOQUEUE. I am not exactly sure everything that setting does but I believe I read that it pulls the images directly from the cache. That setting seems to work great with the RAM Disk.

The downside to that is on a reboot the RAM Disk gets built again and the cache is completely gone. If I could kick off the pre-caching on a system startup things would be close to perfect.

Originally Posted by Fuzzy

...I've settled on the fact the single best way to always get the easiest/best performance, while still allowing real-time updates of fanart, is to run a very large Disk Cache...

I tried out FancyCache with a 4GB cache on the server. I am running extenders at the TVs. I saw some improvement but it did not seems nearly equivalent as the RAM Disk setup. Maybe I need to play around with some settings there.

-smak

[jusjoken]

Originally Posted by smak

On the extenders I set the cache setting to NOQUEUE. I am not exactly sure everything that setting does but I believe I read that it pulls the images directly from the cache. That setting seems to work great with the RAM Disk.
-smak

I would suggest using the default BACKGROUND cache setting as the setting you are picking disables the queue... this means that if you select a media item that has no image in the file cache then gemstone will have to pause and wait for that fanart to load into the cache and will slow down the UI. BACKGROUND and NOQUEUE always check the memory cache and then the file system cache first so they should react the same if the image is already cached... but BACKGROUND will place the request for a NEW image into a queue and process it within a background process to not hold up the UI.

Originally Posted by smak

The downside to that is on a reboot the RAM Disk gets built again and the cache is completely gone. If I could kick off the pre-caching on a system startup things would be close to perfect.
-smak

For this I would need to work out a way for you to call the API externally from the command line which is not built in right now... so the quick answer is no... not at this time.... you can always add it to the issues list on the issues site and we can consider it for future releases.

k

[smak]

I'll go back and investigate the BACKGROUND option and see what happens.

I am also going to go back and tinker around with the FancyCache options and see if I can get that working better for me. That will alleviate the issue on the RAMDisk side.

NOTE: everything was working fine before I went down this path. Just trying to squeeze out everything I can

Thanks,

smak