Is It Possible to have 2 Instances of Rainmeter Running Simultaneously?

[Yincognito]

For me, the first start up has consistently required two executions before things run normally.

Maybe because of the UAC prompt? I don't use such, so it might be a potential reason.

Additionally all of the includes are not working since the #@# variables no longer are in the Documents parent, instead they are in the C drive variant portable folder - so I have no idea how to set the path, other than the literal way rather than the #blabla# way.

Well, if you only have one skin that needs Administrator privileges, as per your posts, I imagine you don't have a ton of includes or !WriteKeyValue bangs in it, and it's simpler from a code point of view. That being said, the #@# variable does work, it just refers to C:\Rainmeter\Skins\[SkinFolder]\@Resources\ path for the portable version (assuming it was installed in C:\ in the installation window), and as long as you move the skin requiring administrator privileges in C:\Rainmeter\Skins\ the #@# will refer to the correct path in your recently moved skin.

It looks to me that you want to have your cake and eat it too in this scenario, which is obviously not going to work. As long as you do things the way each Rainmeter variant is designed to do them, things will start to work.

[CodeCode]

Maybe because of the UAC prompt? I don't use such, so it might be a potential reason.

That is why I was trying to get the duplicate version in the first place. However, even without the UAC requirement, Rainmeter is still miffing me off by not starting on the first initialisation.

Well, if you only have one skin that needs Administrator privileges, as per your posts, I imagine you don't have a ton of includes or !WriteKeyValue bangs in it, and it's simpler from a code point of view. That being said, the #@# variable does work, it just refers to C:\Rainmeter\Skins\[SkinFolder]\@Resources\ path for the portable version (assuming it was installed in C:\ in the installation window), and as long as you move the skin requiring administrator privileges in C:\Rainmeter\Skins\ the #@# will refer to the correct path in your recently moved skin.

I got things going. I was just being dissident and did not really try - my bad :P

It looks to me that you want to have your cake and eat it too in this scenario, which is obviously not going to work. As long as you do things the way each Rainmeter variant is designed to do them, things will start to work.

Well, the idea was to have a lighter weight instance or Rainmeter possibly making the UAC requirement less 'significant'. Incidentally the no Admin Rainmeter still needs two tries to get up and running, however the admin rights given smaller Rainmeter starts flawlessly - after the initial startup of the no Admin Rainmeter instance.

There certainly is something Rainmeter likes to have that it doesn't have until it tries to start that first time after rebooting. After that I can kill Rainmeter and restart it higglety pigglety with no issues - barring there is no reboot between start ups. I'll find what that is then just schedule that little program or whatever to start or be initialised prior to starting Rainmeter - I just have no idea what that 'little thing' is right now. ... it may be a dll, or something so I get the feeling I may be creating a batch file in my future lol.

[CodeCode]

I just thought of something. Perhaps you might be able to help (you being anyone really - but you Yincognito mostly :P ).

I was thinking I could schedule rainmeter to start up on reboot then duplicate the manual process of using task manager to kill the instance. So that is what I have no idea how to do, for now - is how to totally kill rainmeter programmatically on autopilot, so to speak.

Any ideas?

[CodeCode]

Is there a list of cmd arguments for Rainmeter? In the TaskSchd I feel that I may benefit from knowing this as my idea above may produce more predictable results - or rather more reliable result/s.

Thanks.

[jsmorley]

Is there a list of cmd arguments for Rainmeter? In the TaskSchd I feel that I may benefit from knowing this as my idea above may produce more predictable results - or rather more reliable result/s.

Thanks.

The only command line arguments must be to an already running instance of Rainmeter, and are just the !Bangs that are available. There are no command line arguments you can use when starting Rainmeter. Keep in mind that if a !Bang has an optional "config" parameter (in other words, what skin will execute the bang), that parameter is not optional from the command line.

https://docs.rainmeter.net/manual/bangs/

[Yincognito]

I just thought of something. Perhaps you might be able to help (you being anyone really - but you Yincognito mostly :P ).

I was thinking I could schedule rainmeter to start up on reboot then duplicate the manual process of using task manager to kill the instance. So that is what I have no idea how to do, for now - is how to totally kill rainmeter programmatically on autopilot, so to speak.

Any ideas?

You can use taskkill, i.e. Taskkill /F /IM Rainmeter.exe - more on this here or here. The "on autopilot" part is achieved by putting the command in a batch file (i.e. a simple text file with the extension .bat) and running that batch at an appropriate moment after startup, e.g. using Control Panel\All Control Panel Items\Administrative Tools\Task Scheduler (where you can define all kinds of triggers).

That being said, I still think the "nice" and "built-in" way should work and that there is no need to force anything to happen. Have you tried running those two Rainmeter instances with some very simple skins (e.g. the default Illustro) and no plugins? I can't say I'm sure about it, because in my debugging experience I saw a LOT of messed up systems, but it should work. From there, assuming the "basic" attempt works, you could identify the culprit by loading skins and / or plugins one by one.

Again, on my system it works. And if it does on my system, then it should work on most if not all decently maintained systems.

[jsmorley]

Edit: There is one command line parameter you can pass to Rainmeter when you start it. You can pass the path and name of an alternative Rainmeter.ini like this:

"C:\Program Files\Rainmeter\Rainmeter.exe" "C:\Temp\MyOtherSetup.ini"

That will start Rainmeter, and use the file MyOtherSetup.ini as the settings file, playing the role that Rainmeter.ini normally plays. All of the other files that are normally in either %APPDATA%\Rainmeter or the program folder if you are running Rainmeter portable, will be created in the folder you specify in the parameter.

[CodeCode]

That being said, I still think the "nice" and "built-in" way should work and that there is no need to force anything to happen.
... because in my debugging experience I saw a LOT of messed up systems, but it should work. From there, assuming the "basic" attempt works, you could identify the culprit by loading skins and / or plugins one by one.

Again, on my system it works. And if it does on my system, then it should work on most if not all decently maintained systems.

I agree completely. I have been going about this the wrong way entirely.
After you mentioning a culprit might exist, I immediately thought of a couple candidates.
There are four, and separately they run but if more than one the issue resurfaces.
So without these 'candidates' my Rainmeter starts on the first try in UAC mode.
So, I will attach these culprits here but perhaps we should move over to the Skins Help forum?

PC Stats Bugged Somehow_xx.xx.rmskin

[Yincognito]

I agree completely. I have been going about this the wrong way entirely.
After you mentioning a culprit might exist, I immediately thought of a couple candidates.
There are four, and separately they run but if more than one the issue resurfaces.
So without these 'candidates' my Rainmeter starts on the first try in UAC mode.
So, I will attach these culprits here but perhaps we should move over to the Skins Help forum?
PC Stats Bugged Somehow_xx.xx.rmskin

Hmm...I don't know - it's up to you if you want to create another thread for this or not. From a topic point of view this could continue here as the issues are related, but if you think it will have more visibility in the Skins Help section, feel free to create a thread for it.

Generally though, the debugging aspect of the code is the job of the skin designer - I don't know if you'll find folks willing to test each skin for you in the 2 admin + non admin instances' scenario and walking though all the lines of the code to find what causes the misbehavior. That being said, make sure you point out which are those 4 potential culprits (from the more than 4 INI files in the package) and in what circumstances Rainmeter doesn't start from the 1st try.

[CodeCode]

Hmm...I don't know - it's up to you if you want to create another thread for this or not. From a topic point of view this could continue here as the issues are related, but if you think it will have more visibility in the Skins Help section, feel free to create a thread for it.

Generally though, the debugging aspect of the code is the job of the skin designer - I don't know if you'll find folks willing to test each skin for you in the 2 admin + non admin instances' scenario and walking though all the lines of the code to find what causes the misbehavior. That being said, make sure you point out which are those 4 potential culprits (from the more than 4 INI files in the package) and in what circumstances Rainmeter doesn't start from the 1st try.

Ok. I am going to digress.
I will get going on debugging on my own for now.
Mostly these have been designed or redesigned completely by me, so I am pretty sure there are going to be many reboots going, and no one should do that for me.

Thanks, since I can now start Rainmeter on the first try now - so mission accomplished LOL.