[User 224999]

Poster.gif (.gifs are no longer in userdata folder animatedgifs. I remember you said you moved them but this problem existed when they used to be located there too. Maybe gifs themselves are the underlying problem? I disabled Prefer Animated Poster if available. That setting only disables gifs pulled in from the database, where ever that is. CUSTOM gifs I have manually added (because they are not in the database, although I submitted them to someone who said they maintained it and would add them) reside in the title folders with all the artwork. THESE are spinning up drive(s) to access.

Hmmmm, I am getting somewhere now. I added CUSTOM gifs to Kodi\userdata\addon_data\script.module.metadatautils and to Kodi\userdata\addon_data\script.module.skin.helper.artutils. This is no longer accessing HDD's. Fixed now, sort of. That one is my own fault and anyone else doing the same.
*EDIT*
A day has went by and now HDD's are being called for gifs again. I'm lost at this point. I do know it is accessing drives for animated poster .gifs and nothing else because logo is disabled in skin. With logo enabled, it too accesses drives.

There is your issue... You placed animated art within your media folders which is NOT supported. The texture cache is skipped for animated gifs so you really need to make sure that you place the animated gifs on a local drive drive that is always on.
That's the reason that by default the animated gifs are placed in the addon_data folder on the local drive.

logo.png is the only problem now. This is still being accessed from HDD's.
If I disable Show Clear Logo if available top center, logo.png is no longer accessed and all is well. I have custom logo but nothing custom being accessed. These are in database scraper.
I would like to use logo and clearlogo if possible but will turn off for now. Maybe you can help with this and check skin code? I don't think it's me? Thank you for the hints. Happy!

I discovered a small bug in the skin. For the clearlogo, it wasn't requesting the clearlogo with the backgroud property (load in background). Somehow I suspect that this also forced it to grab the local copy and not the one in texture cache.
I'll post new update (beta) later today or tomorrow, please give that a test drive.