I recently bought a 2014 Mac Mini to replace my old 2009 Mac Mini as my main XBMC server, and I've been disappointed in the negligible speed increases (when I talk about speed, I mean the responsiveness and load times when scrolling through a library of 2,000+ movies with fanart, logos, posters, etc.). I probably should have bought a Mac Mini with an SSD, but I digress.
Anyway, I've been reading a bit about path substitution. A few questions, for anyone who has done this:
1) Ultimately, I want to offload my XBMC userdata folder to a faster drive, such as an external SSD. Is that correct?
2) Could I also use an SD card or a speedy USB key instead of an SSD? My userdata folder is only 3.8GB, which would perhaps make a 128GB SSD a bit of overkill.
Any help or suggestions greatly appreciated. Again, my only goal here is to speed up the time it takes to scroll through my XBMC library.
With your goal in mind, perhaps a read of the
advanced settings wiki might bring more joy. Curious to see what influence speed to access thumbs etc might have on performance, I redirected to a ram drive with path substitution and was impressed. But over time I've noted that Kodi caching holds a number of prefetch thumbs etc which is about the same as ram. I have since replaced my main O/S drive spinning disk with an SSD and while it's no slouch, and I no longer see cover gaps, I'm not getting a lot more than I had.
If you do decide on a hardware solution, putting your O/S on SSD would be the smartest move. You will find the practical speeds of USB/Flash drives are just not in the same league as SSD, but an extranal SSD needs to access your main system somehow, if it's communicating at USB1 or 2 (yukky speeds) while USB 3 is more comparable with e-sata, and on a MAC I would would think Thunderbolt.
Things that slow the works down, large amount of extrafanart, extrathumbs, excessively large folders & directories... even the O/S needs time to list 3-400 files. A lot of gfx extras, logo's disks, music, oversized art that has to be handled in real time etc.. anything that calls the web with background tasks.
You cannot offload your entire userdata, even where path substitution is concerned. The wiki page is pretty clear on this and also being a somewhat experimental feature even though it works for some cases.
Now. I dont use ssd for anything kodi never have and very likely never will, I have tested it and deemed it a waste of hw for negligible gains + on ssd with Linux you need on a dedicated kodi htpc delay kodi starting until network is ready, which is still adding more tweaks so imo not the living up to the ssd hype, maybe in a few years..
Personal preferences aside, my system is very responsive boots in 20 seconds and is ready to use, browsing is fast and loads everything faster than I can browse the lib thumbnails wise etc. I think this is due to a well maintained and mature library and well pruned texture13.db and well cached system and this is the trick I believe is to make sure your library/thumbs is indeed all cached. (that means all the artowork you see)
The reason is the caching takes place while you browse, on any normal system it takes a few weeks of browsing around the library to trigger all caching (assuming you browse through the lot over time) A ssd is making this faster but it wont get rid of it, simply because thats not the way kodi works, you still need to browse the lib and once done I put my hdd against any ssd. To give you some idea, I press down and its scrolling as fast as system can and everything is loaded instantly.
My userdata is 9GB pruned and cleaned.
Enter Texturecache.py all above made easy and simpler than fighting and coming up with excuses, buy better systems and yet more OCD type fixing what isn't broke (we all do it though)
Texturecache.py can pre cache everything and ensure that once done you can also use it to prune and do garbage collection to said texture folders/thumbs and databases etc and keep everything tip-top.
Running texturecahe.py with C would do that of course you need a fully setup machine for this, try it on yours and see things getting noticeably faster and more responsive and with some patience
Thanks PatK and Universal for taking the time to read and answer.
It sounds, if I'm understanding things correctly, that an SSD perhaps won't be as much of a benefit as I'd like, and that giving XBMC time to cache my textures would be of greater benefit, right?
(I've been making lots of changes to my library artwork lately, so perhaps that's part of the slowness, and some of the texture changes simply need to be cached.)
Sorry but I have to laugh, you brought a MAC and you want it to go faster? Buy a PC instead lol
Use the tool I recommended to speed up the caching.
* un1versal points to http://forum.kodi.tv/showthread.php?tid=158373
run with ./texturecache.py C
That force caches everything whether you browse or not.
For cleaning up this is what I do usually.
./texturecache.py vclean
./texturecache.py aclean
to clean video/audio databases.
./texturecache.py P
for pruning
./texturecache.py R
removing remnenats rubbish
./texturecache.py Xd
Deleting the id that dont have anything associated with anymore from databases.
And you should start to notice a definitive improvement... The script allows so so much more. use it read it and fear not for you should be armed with backup.
Thanks Universal, I'll give Milhouse's script a shot.