Rainmeter Install Directories Issue

[Dax]

Recently, I installed updates to the only two Rainmeter skins I use: Neon Space Pro and DropTop4. After doing so, the components of one or both of these skins would disappear, and resist reinstalling. I uninstalled Rainmeter (I followed the "Clean Uninstall" process from the documentation) and tried reinstalling. I got the message: "There are no available skins at: C:\Users\XXXX1\Documents\Rainmeter\Skins\"
This seemed odd because the "XXXX1" was my first name, but NOT the name Windows calls my Microsoft account.
The directory C:\Users\XXXX1\Documents exists, but it's empty.
When I printed out the info from Rainmeter, here's what I see:
Rainmeter 4.5.18.3727 (64-bit)
Language: English (1033)
Build time: 2023-07-31 11:58:37
Windows 11 Pro 23H2 (build 22631.3810) 64-bit - English (1033)
Path: C:\Program Files\Rainmeter\
SkinPath: C:\Users\XXXX1\Documents\Rainmeter\Skins\
SettingsPath: C:\Users\XXXX2\AppData\Roaming\Rainmeter\
IniFile: C:\Users\XXXX2\AppData\Roaming\Rainmeter\Rainmeter.ini

FYI, when I installed Windows11 a long time ago, I relocated my Documents folder to D:\Documents (rather than C:\Users\XXXX2\Documents), and have never had a problem with Rainmeter or any other installed program.

Can someone provide insight about why the SkinPath would be a directory that doesn't even exist, and why it would be in a folder in the C:\Users directory that does NOT correspond to my account name where everything else is stored, and, more importantly, what can I do to fix this??? I tried editing the

[balala]

Can someone provide insight about why the SkinPath would be a directory that doesn't even exist, and why it would be in a folder in the C:\Users directory that does NOT correspond to my account name where everything else is stored, and, more importantly, what can I do to fix this??? I tried editing the

• Close Rainmeter (I mean right click its icon in the Notification Area and click Exit). Alternatively instead of closing Rainmeter, you might try right clicking the Rainmeter icon and click Edit settings, however I'd better recommend to close it.
• Locate the following file: C:\Users\XXXX2\AppData\Roaming\Rainmeter\Rainmeter.ini.
• Locate the [Rainmeter] section of this file. Check the SkinPath option, stored into this section. Rainmeter looks for skins in the folder given by this option. Replace the option to the proper one (SkinPath=D:\Documents\Rainmeter\Skins\).
• Move (copy) all configs (Neon Space Pro and DropTop4 most probably) into this D:\Documents\Rainmeter\Skins\ folder.
• Restart Rainmeter.

Now Rainmeter should see the stored and existing skins.

FYI, when I installed Windows11 a long time ago, I relocated my Documents folder to D:\Documents (rather than C:\Users\XXXX2\Documents), and have never had a problem with Rainmeter or any other installed program.

Same here: my Documents folder is exactly on the same place (D:\Documents), skins being stored at D:\Documents\Rainmeter\Skins\. Same way as you, had no problems at all over more than a decade since I'm using Rainmeter.

[Yincognito]

More or less what balala said, for another occurrence of this issue:
https://forum.rainmeter.net/viewtopic.php?t=43891

As for the reason why that happened, the account from which you originally installed Rainmeter a long time ago might have been either XXXX1 or XXXX2 (which would explain why some files are there), and it's possible that your Documents folder relocation wasn't performed 100% correctly / completely at the time (e.g. either while Rainmeter was running, or after Rainmeter was installed - which would explain why some of these filders are considered instead of the D: location), not to mention possible account name issues, changes or creation in the meantime. Or, might be some unknown Rainmeter bug in such relocation / reinstallation / multiuser / OS upgrade scenarios, though that's less likely.

When I had the habit of relocating my Users folder a long time ago, I always did it very shortly after installing Windows, while there were no other programs installed yet, and didn't encounter major issues with that approach. I know these things "should" work fine afterwards too, but I generally don't like to take chances when it comes to doing things cleanly, from the start. OS upgrades are a similar example, a higher probability for issues than when doing it cleanly through bare installation of the new version. Planning ahead has its benefits.