MSIRGB applies breathing effect if PC is unplugged

[EhGuppy]

I have to move my PC sometimes, and whenever I do, MSIRGB applies the "breathing" effect and I can't turn it off. It breathes between the selected color and white. I have a bunch of single-color scripts (I've attached one as an example) and no matter which one I pick or what I do, the effect is on. If I install MysticLight and then uninstall it immediately after, I can control MSIRGB normally again. But when I do this, it resets all of my lighting, so I have to reinstall iCue as well and reset my lighting settings back to normal, and uninstall that too (iCue acts as a hardware monitor that can cause issues)

having to reinstall and uninstall two separate programs each time is a pain, so I'm hoping there's a fix to this one. It's only an issue when the PC is unplugged, for any amount of time. It doesn't happen when the PC is shut down.

My motherboard is the B450 Tomahawk Max 01 - Red.txt

[ixjf]

This is a known issue. See #161. I still don't know why it happens.

[EhGuppy]

Thanks. If I had to guess, it might have something to do with how the colors are reversed on certain motherboards (mine included) It may also be reversing the breathing settings when it’s accessing from the hardware, so that’s why it breathes from the selected color to white instead of from the selected color to black, or off. My scripts all have breathing set to “false” so it may be reversing that too.

Again, I’m just guessing. Thanks again for making this program, I love it. I know you’re busy so I don’t really expect this problem to be fixed, but I thought it would be worth posting because it might help isolate the issue.

[ixjf]

If that were the case, then setting breathing to true would stop it, right?

[EhGuppy]

I haven’t tried unplugging the computer while I have a breathing script on, but I ought to try it just to see if anything changes. The problem seems to be that it only affects the breathing setting when it’s accessing from the hardware instead of the software (if that’s how it works?) so if I were to do that, changing the colors from inside the program would start to apply the breathing effect instead.

[ixjf]

Sorry for the delay. Did you figure anything out?

[ixjf]

Can you give me an update? Otherwise I'll close this issue.

[EhGuppy]

Sorry, totally forgot to update you and just learned to put up with the issue. I just tested it again, and it seems that no matter what I do, when I unplug my computer and plug it back in, it applies the breathing effect. I can't turn it off. Have to install MysticLight to get it working, which resets iCue, etc.

I even tried applying the breathing effect and unplugging, with the logic that if the colors are opposite, maybe the breathing effect is too. Instead, it cycles between white and off instead of white and the selected color.

[ixjf]

Can you follow this? https://github.com/ixjf/MSIRGB/issues/170#issuecomment-773279710

Would like to see if there's no interference from other programs, just in case. But I'll check if I haven't fucked something up in MSIRGB too.

[EhGuppy]

Here ya go. Thanks for following up on this, it would be great to solve this issue. userprc.txt drivers.txt

[ixjf]

Yeah, this seems fine. I would like to ask you if you could try the DLL attached.

MSIRGB.DLL.zip

It shouldn't solve your problem. What I added was some code to dump the state of the chip at startup. Whenever you run MSIRGB, it will create two files, one called "msirgb_dump_bank_12h.txt" and another called "msirgb_dump_bank_9h.txt" in your %temp% directory (just type %temp% into any address bar). If you can't find the files in that folder, look in these ones:

1. The path specified by the TMP environment variable.
2. The path specified by the TEMP environment variable.
3. The path specified by the USERPROFILE environment variable.
4. The Windows directory (C:\Windows\TEMP, I think).

What I would like you to do is to simulate what happens when you move your PC. When you get the breathing effect bug, go to the temp directory and upload the dump files. Then, fix the issue by doing whatever you did before, and rerun MSIRGB, uploading the new dumps.

[EhGuppy]

It turns out, that DLL did fix my problem. I think I was using your old version 2.2.1.2, and that's why I was still getting that breathing effect. There are still a couple of very minor problems, but they don't really bother me. When the computer is restarted, MSIRGB starts white and then defaults to red when the system is fully started. But, it's incredibly easy to just start a script after boot to get the desired effect. The other issue is that the old version gets a much better orange color than the new one. Here's a couple of pictures comparing the LEDs set one point away from red.

02 - Burnt Orange.txt

These pictures don't capture it quite right, but the new version is noticeably yellow instead of orange. With the old version, it's just about the same color as my ram/fans. But, every single other color is perfect. Orange is the only color with any issue.

Again, these problems are really small and I'm more happy to have the booting issue solved :) Thanks

[EhGuppy]

The above issue with Orange not being right was also posted here https://github.com/ixjf/MSIRGB/issues/149 These pictures demonstrate the issue, though

[ixjf]

When the computer is restarted, MSIRGB starts white and then defaults to red when the system is fully started.

Not sure I'm following.

These pictures don't capture it quite right, but the new version is noticeably yellow instead of orange. With the old version, it's just about the same color as my ram/fans. But, every single other color is perfect. Orange is the only color with any issue.

Wait, RGB (F, 1, 0) gives you red with colours inverted...?

[ixjf]

Also, did you try with the release 2.3.0 build rather than the debug DLL?

[EhGuppy]

Wait, RGB (F, 1, 0) gives you red with colours inverted...?

This is why I say the pictures aren't perfect at capturing it. The actual colors are a lot closer to these:

https://colorpicker.me/#ff6000 https://colorpicker.me/#ff8a00

The top one is close to red, but definitely not red. Version 2.2.1.2 can get that deep of an orange before turning fully red. The bottom one is what 2.3.0 achieves, the closest it can be to red without being red. That is quite a gap between the two colors, so it's impossible to get a deep orange (or burnt orange) glow with the new version.

The colors being inverted doesn't really seem to have anything to do with it. Every other color operates the same, but for some reason orange has a vastly reduced range. I don't know why it's different, but it's easy to see by comparing between 2.2.1.2 and 2.3.0.

When the computer is restarted, MSIRGB starts white and then defaults to red when the system is fully started.

I run a script to get the LEDs purple. When I unplug the computer, on boot those LEDs are white through bios/loading, and then when windows loads they turn red. They never turn purple again even though the script is supposed to run on boot, so I have to manually run the script to get them purple again. No big deal, and it only happens specifically when the computer is unplugged for 20+ seconds

Also, did you try with the release 2.3.0 build rather than the debug DLL?

This is what I'm running now and it fixed the problem the same way your .dll did. The problem definitely was that I was running an older version. I remember avoiding 2.3.0 because I still wanted to use that deep orange in my case.

[ixjf]

Right. I noticed there was a problem with orange and red, but I had no reason to believe inverting colours had anything to do with it. But I'll play around with it, see what I can find.

I run a script to get the LEDs purple. When I unplug the computer, on boot those LEDs are white through bios/loading, and then when windows loads they turn red. They never turn purple again even though the script is supposed to run on boot, so I have to manually run the script to get them purple again. No big deal, and it only happens specifically when the computer is unplugged for 20+ seconds

Sounds like a known issue (#159 and others). I really don't know why it happens. I don't believe it's MSIRGB's fault? Feels like the chip is being reset when Windows starts, so the settings MSIRGB applies are erased.

[EhGuppy]

I don't think inverting colors has anything to do with it either, but who knows. It's weird that it happens, but it's not really a big problem. It would be nice to get the full color range back, though.

Sounds like a known issue (#159 and others). I really don't know why it happens. I don't believe it's MSIRGB's fault? Feels like the chip is being reset when Windows starts, so the settings MSIRGB applies are erased.

That's definitely something that's happening in the startup processes. Maybe unplugging the computer clears certain processes that aren't necessary to the system, including the MSIRGB script service. Just speculation.

The main issue is solved, so feel free to close it. Thanks again!