User’s should be able to clear the cache from the configurator. This should also ensure that MB is already closed. It will also enable to long standing bug where cache will not cleared properly via the GUI to be closed off and that functionality to be removed. It makes no sense being in the GUI since you are immediately directed back to WMC anyway.
There is also a lot of confusion for me anyway about what to manually clear even though there is an KB article on the subject. This could be address here by ensuring only what the user requires to be removed actually is. This could be done by a yes or no with a brief explanation of each option.
For example – User selects clear cache. A pop-up window appears for each folder within the cache directory and a brief explanation is in the pop-up like “You are about to clear the ‘display’ cache. This cache contains information about what view settings are used for your media collections and their various sub-levels. All folder display settings will be lost. Are you sure you want to continue?”
I agree. It would solve the current limitation of the “Clear Cache” function as indicated in this topic.
A little design mockup is in the design tab.
Yeah approved, with a caveat, I really wish stuff was designed in such a way that clearing cache was a very rare thing.
We need to make this an advanced feature in configurator so most people do not see it.
Why is the imagecache in a different folder to the rest of the cache? Why not include that within cache, \cache\Images for example? I suppose with this implementation the location does not really matter but I always find myself wondering if whenever someone advised users to clear cache whether they mean this one too.
Someone want to give this a quick test…
Someone want to give this a quick test…
For some reason, the playstate folder acts differently than the others. I cannot figure out why. Sometimes there is an error re-creating it (actually all the folders are deleted and then re-created). One of my machines had problems and the other one didn’t.
I forgot to implement display, try it again…
I don’t delete the auto playlists. Can’t see any reason to mess with that…
For some reason, the playstate folder acts differently than the others. I cannot figure out why. Sometimes there is an error re-creating it (actually all the folders are deleted and then re-created). One of my machines had problems and the other one didn’t.
At first I thought I had a permissions issue, since I did still see the playstate folder after it was cleared, but I couldn’t access it. All permissions were gone. Only after restarting explorer 3 times the folder actually disappeared.
Why not delete all files in the folders instead of deleting the folders themselves?
Deleting the folders could cause issues if people use junction points for them for a solution like this. (Someone should also test this that actually has a shared playstate…)
I forgot to implement display, try it again…
Updated version works.
I don’t delete the auto playlists. Can’t see any reason to mess with that…
Fair enough. Just reported it :)
Why not delete all files in the folders instead of deleting the folders themselves?
.NET doesn’t provide a method to delete all files in a folder easily. I would have to actually iterate through them all. With a cache folder with potentially tens of thousands of items, I didn’t want to do that. Maybe I can do it for just the display and playstate ones…
[edit] Okay, I changed the playstate and display routines to iterate through files instead of blowing the directory. Please re-download and see if it behaves better.